Re: [git patches] IDE update

Ondrej Zary
2005-07-05T21:49:25Z

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