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
> > 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
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 queue
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
> 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
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
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
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 sleep
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 place
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 exporting
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
so.
12 matches
Mail list logo
