On Mon, Jun 04 2007, Carsten Otte wrote:
> Jens Axboe wrote:
> >Most people should not fiddle with it, the defaults are there for good
> >reason. I can provide a blk_queue_unplug_thresholds(q, depth, delay)
> >helper that you could use for the virtualized drivers, perhaps that
> >would be better fo
Jens Axboe wrote:
> Most people should not fiddle with it, the defaults are there for good
> reason. I can provide a blk_queue_unplug_thresholds(q, depth, delay)
> helper that you could use for the virtualized drivers, perhaps that
> would be better for that use?
Yea, we should'nt change the defaul
On Mon, Jun 04 2007, Rusty Russell wrote:
> On Mon, 2007-06-04 at 15:43 +0200, Jens Axboe wrote:
> > On Mon, Jun 04 2007, Carsten Otte wrote:
> > > Jens Axboe wrote:
> > > >On Fri, Jun 01 2007, Carsten Otte wrote:
> > > >>With regard to compute power needed, almost none. The penalty is
> > > >>lat
On Mon, 2007-06-04 at 15:43 +0200, Jens Axboe wrote:
> On Mon, Jun 04 2007, Carsten Otte wrote:
> > Jens Axboe wrote:
> > >On Fri, Jun 01 2007, Carsten Otte wrote:
> > >>With regard to compute power needed, almost none. The penalty is
> > >>latency, not overhead: A small request may sit on the req
On Mon, Jun 04 2007, Carsten Otte wrote:
> Jens Axboe wrote:
> >On Fri, Jun 01 2007, Carsten Otte wrote:
> >>With regard to compute power needed, almost none. The penalty is
> >>latency, not overhead: A small request may sit on the request queue to
> >>wait for other work to arrive until the queu
Jens Axboe wrote:
> On Fri, Jun 01 2007, Carsten Otte wrote:
>> With regard to compute power needed, almost none. The penalty is
>> latency, not overhead: A small request may sit on the request queue to
>> wait for other work to arrive until the queue gets unplugged. This
>> penality is compensa
Rusty Russell wrote:
> Is the noop scheduler significantly worse than hooking directly into
> q->make_request_fn?
The noop scheduler does do request merging, and has the same device
plug latency as other schedulers.
so long,
Carsten
---
On Fri, 2007-06-01 at 09:10 +0200, Carsten Otte wrote:
> Rusty Russell wrote:
> > What's the overhead in doing both?
> With regard to compute power needed, almost none. The penalty is
> latency, not overhead: A small request may sit on the request queue to
> wait for other work to arrive until th
On Fri, Jun 01 2007, Carsten Otte wrote:
> Rusty Russell wrote:
> >Now my lack of block-layer knowledge is showing. I would have thought
> >that if we want to do things like ionice(1) to work, we have to do some
> >guest scheduling or pass that information down to the host.
> Yea that would only w
Rusty Russell wrote:
> Now my lack of block-layer knowledge is showing. I would have thought
> that if we want to do things like ionice(1) to work, we have to do some
> guest scheduling or pass that information down to the host.
Yea that would only work on the host: one can use ionice to set the i
On Thu, 2007-05-31 at 14:57 +0200, Carsten Otte wrote:
> Rusty Russell wrote:
> > Example block driver using virtio.
> >
> > The block driver uses outbufs with sg[0] being the request information
> > (struct virtio_blk_outhdr) with the type, sector and inbuf id. For a
> > write, the rest of the s
Carsten Otte wrote:
> Troy Benjegerdes wrote:
>
>> This kind of a claim needs some benchmark data to document it.
>>
> We've implemented both for our vdisk driver on 390. At least on our
> platform, merging in the host is preferable because vmenter/vmexit is
> very fast and we would merge
Troy Benjegerdes wrote:
> This kind of a claim needs some benchmark data to document it.
We've implemented both for our vdisk driver on 390. At least on our
platform, merging in the host is preferable because vmenter/vmexit is
very fast and we would merge twice because we submit the result via
i
On Thu, May 31, 2007 at 02:57:27PM +0200, Carsten Otte wrote:
> Rusty Russell wrote:
> > Example block driver using virtio.
> >
> > The block driver uses outbufs with sg[0] being the request information
> > (struct virtio_blk_outhdr) with the type, sector and inbuf id. For a
> > write, the rest o
Rusty Russell wrote:
> Example block driver using virtio.
>
> The block driver uses outbufs with sg[0] being the request information
> (struct virtio_blk_outhdr) with the type, sector and inbuf id. For a
> write, the rest of the sg will contain the data to be written.
>
> The first segment of th
Example block driver using virtio.
The block driver uses outbufs with sg[0] being the request information
(struct virtio_blk_outhdr) with the type, sector and inbuf id. For a
write, the rest of the sg will contain the data to be written.
The first segment of the inbuf is a result code (struct
vi
16 matches
Mail list logo
