Messages in this thread | | | Date | Tue, 05 Jul 2005 23:39:25 +0200 | From | Ondrej Zary <> | Subject | Re: [git patches] IDE update |
| |
Jens Axboe wrote: > On Tue, Jul 05 2005, Linus Torvalds wrote: > >> >>On Tue, 5 Jul 2005, Jens Axboe wrote: >> >>>Looks interesting, 2.6 spends oodles of times copying to user space. >>>Lets check if raw reads perform ok, please try and time this app in 2.4 >>>and 2.6 as well. >> >>I think it's just that 2.4.x used to allow longer command queues. I think >>MAX_NR_REQUESTS is 1024 in 2.4.x, and just 128 in 2.6.x or something like >>that. > > > But for this case, you only have one command in flight. hdparm is highly > synchronous, my oread case is as well. > > >>Also, the congestion thresholds are questionable: we consider a queue >>congested if it is within 12% of full, but then we consider it uncongested >>whenever it falls to within 18% of full, which I bet means that for some >>streaming loads we have just a 6% "window" that we keep adding new >>requests to (we wait when we're almost full, but then we start adding >>requests again when we're _still_ almost full). Jens, we talked about this >>long ago, but I don't think we ever did any timings. > > > In theory, the ioc batching should handle that case. But as you can see > from recent commits, I'm not very happy with how this currently works. > It should not impact this testing, though. > > >>Making things worse, things like this are only visible on stupid hardware >>that has long latencies to get started (many SCSI controllers used to have >>horrid latencies), so you'll never even see any difference on a lot of >>hardware. > > > IDE still has much lower overhead per command than your average SCSI > hardware. SATA with FIS even improves on this, definitely a good thing! > > >>It's probably worth testing with a bigger request limit. I forget what the >>/proc interfaces are (and am too lazy to look it up), Jens can tell us ;) > > > It's /sys/block/<device>/queue/nr_requests now, can be changed at will. > Tested with default 128, 1024 and 4 (minimum) and no change.
-- Ondrej Zary - 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/
| |