Re: [PATCH] cfq-iosched: non-rot devices do not need queue merging

[Jens Axboe <jens.axboe@oracle.com>]

On Wed, Dec 30 2009, Corrado Zoccolo wrote:
> On Wed, Dec 30, 2009 at 10:11 PM, Jens Axboe <jens.axboe@oracle.com> wrote:
> > On Wed, Dec 30 2009, Corrado Zoccolo wrote:
> >> On Wed, Dec 30, 2009 at 7:45 PM, Jens Axboe <jens.axboe@oracle.com> wrote:
> >> > On Wed, Dec 30 2009, Corrado Zoccolo wrote:
> >> >> Non rotational devices' performances are not affected by
> >> >> distance of requests, so there is no point in having overhead
> >> >> to merge queues of nearby requests.
> >> >
> >> > If the distance is zero, it may still make a big difference (at least
> >> > for writes). This check would be better as "ncq and doesn't suck", ala
> >> >
> >> >        blk_queue_nonrot(q) && tagged
> >> >
> >> > like we do elsewhere.
> >>
> >> For reads, though, even flash cards and netbook ssds are completely
> >> unaffected. I have done few experiments on my available disks:
> >> * http://dl.dropbox.com/u/3525644/service_time.png (I used the
> >> program: http://dl.dropbox.com/u/3525644/stride.c to get the graphs).
> >
> > Completely agree, it's writes that matter (as mentioned).
> >
> >> For distance 0, I think request merging will be more effective than
> >> queue merging, moreover I think the multi-thread trick to have large
> >
> > Definitely true, but we don't allow cross cfqq merges to begin with.
> >
> >> I/O depth is used for reads, not writes (where simply issuing buffered
> >> writes already achieves a similar effect), so I think it is safe to
> >> disable it for all non-rotational devices.
> >
> > That still leaves direct writes. Granted it's a problem with a huge
> > scope, but still.
> Maybe I can mark sync queues that have write requests, and only add
> those ones to the prio tree.

That sounds like a solution and avoids the merge/breakup pain for (by
far) most use cases.

> For writes, merging queues (and therefore requests) can probably help
> even the smart ssds.

Yes, but we are getting to the point of having to be more careful about
CPU cycles on SSDs. But lets do it, I'll be spending a good chunk of
time on that very shortly anyway.

-- 
Jens Axboe