Messages in this thread | | | Subject | Re: RFC on io-stalls patch | From | Chris Mason <> | Date | 13 Jul 2003 12:20:39 -0400 |
| |
On Sun, 2003-07-13 at 05:01, Jens Axboe wrote: > On Sat, Jul 12 2003, Chris Mason wrote: > > On Sat, 2003-07-12 at 03:37, Jens Axboe wrote: > > > > > > I believe the new way provides better overall read performance in the > > > > presence of lots of writes. > > > > > > I fail to see the logic in that. Reads are now treated fairly wrt > > > writes, but it would be really easy to let writes consume the entire > > > capacity of the queue (be it all the requests, or just going oversized). > > > > > > I think the oversized logic is flawed right now, and should only apply > > > to writes. Always let reads get through. And don't let writes consume > > > the last 1/8th of the requests, or something like that at least. I'll > > > try and do a patch for pre4. > > > > If we don't apply oversized checks to reads, what keeps a big streaming > > reader from starving out all the writes? > > It's just so much easier to full the queue with writes than with reads. >
Well, I'd say it's a more common problem to have lots of writes, but it is pretty easy to fill the queue with reads.
> > The current patch provides a relatively fixed amount of work to get a > > request, and I don't think we should allow that to be bypassed. We > > might want to add a special case for synchronous reads (like bread), via > > a b_state bit that tells the block layer an immediate unplug is coming > > soon. That way the block layer can ignore the oversized checks, grant a > > request and unplug right away, hopefully lowering the total number of > > unplugs the synchronous reader has to wait through. > > > > Anyway, if you've got doubts about the current patch, I'd be happy to > > run a specific benchmark you think will show the bad read > > characteristics. > > No I don't have anything specific, it just seems like a bad heuristic to > get rid of. I can try and do some testing tomorrow. I do feel strongly > that we should at least make sure to reserve a few requests for reads > exclusively, even if you don't agree with the oversized check. Anything > else really contradicts all the io testing we have done the past years > that shows how important it is to get a read in ASAP. And doing that in > the middle of 2.4.22-pre is a mistake imo, if you don't have numbers to > show that it doesn't matter for the quick service of reads.
I believe elevator-lowlatency tries to solve the 'get a read in ASAP' from a different direction, by trying to limit both the time required to get a request and the time for required for the unplug to run. Most of my numbers so far have been timing reads in the face of lots of writes, where elevator-lowlatency is a big win.
It should make sense to have a reserve of requests for reads, but I think this should be limited to the synchronous reads. Still, I haven't been playing with all of this for very long, so your ideas are much appreciated.
-chris
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |