Messages in this thread | | | Date | Sun, 13 Jul 2003 21:19:21 +0200 | From | Andrea Arcangeli <> | Subject | Re: RFC on io-stalls patch |
| |
On Sun, Jul 13, 2003 at 11:01:16AM +0200, Jens Axboe wrote: > 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
well, it's not an heuristic, it's a simplification and it will certainly won't provide any benefit (besides saving some hundred kbytes of ram per harddisk that is a minor benefit).
> 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
Important for latency or throughput? Do you know which is the benchmarks that returned better results with the two queues, what's the theory behind this?
> 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.
Is it latency or throughput that you're mainly worried about? Latency certainly isn't worse with this lowlatency improvement (no matter one or two queues, that's a very minor issue w.r.t. to latency).
I could imagine readahead throughput could be less likely to be hurted by writes with the two queue. But I doubt it's very noticeable.
However I'm not against re-adding it, clearly there's a slight benefit for reads in never blocking in wait_for_request, I just didn't consider it very worthwhile since they've to block anyways later normally for batch_sectors anyways, just like every write (in a congested I/O subsystem - when the I/O isn't congested nothing blocks in the first place).
Andrea - 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/
| |