> >Seems that way. With the 2.4.21 code, a read might easily get a
> >request, but then spend forever waiting for a huge queue of merged
> >writes to get to disk.
> But it is the job of the io scheduler to prevent this, isn't it?
Yes, but the 2.4.21 code doesn't do it.
> >I believe the new way provides better overall read performance in the
> >presence of lots of writes.
> I don't know how that can be, considering writers will consume
> basically limitless requests. What am I missing?
There is a limit on the total amount of IO in flight (4MB by default,
reads/writes combined). We can make this a harder limit by disallowing
merges on any requests present at the time of an unplug. Perhaps I'm
not reading your question correctly?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/