Giuliano Pochini wrote:
>
> > > This brings me to another point. We probably want some generic
> > > interfaces in ll_rw_blk to unplug individual queues, where you can either
> > > specify either the actual queue a kdev_t. Some of the places, (such as
> > > __wait_on_buffer()) it might make
> > This brings me to another point. We probably want some generic
> > interfaces in ll_rw_blk to unplug individual queues, where you can either
> > specify either the actual queue a kdev_t. Some of the places, (such as
> > __wait_on_buffer()) it might make more sense to unplug just the que
Eric, sorry for the late reply.
On Thu, 7 Sep 2000, Eric Youngdale wrote:
>The oddness is this. We were observing stalls in the processing of
>commands that was traced to the fact that the queue had remained plugged
>for an excessive amount of time. The stalls last for about 5 seconds or
>
On Thu, Sep 07 2000, Jens Axboe wrote:
> request_queue_t *q = blk_get_queue(dev);
> generic_unplug_device(q);
>
> And that would be it. This is already exported and I use it in a
Aghr, it's exported in my tree only I see... Oh well, as I wrote I
don't see any harm in actually exporti
On Thu, Sep 07 2000, Eric Youngdale wrote:
> This brings me to another point. We probably want some generic
> interfaces in ll_rw_blk to unplug individual queues, where you can either
> specify either the actual queue a kdev_t. Some of the places, (such as
> __wait_on_buffer()) it might make
> It is. Not unplugging the queue results in higher throughput
> when running a benchmark load, but seems to really harm
> system throughput (and cause stalls) in /real/ loads.
>
> This is most likely due to the fact that in most real life
> loads we have to write data and metadata all over the pl
On Thu, 7 Sep 2000, Eric Youngdale wrote:
> The oddness is this. We were observing stalls in the
> processing of commands that was traced to the fact that the
> queue had remained plugged for an excessive amount of time.
> The stalls last for about 5 seconds or so.
Which is the default sl
Doug Gilbert and I ran across
some weirdness in the way the block device queues are plugged/unplugged.
It turned up with some benchmarks of the SCSI generics driver - with the new
queueing code, the generics driver is inserting requests into the same queue
that block device requests a
8 matches
Mail list logo
