Re: [git patches] IDE update

[Jens Axboe <axboe@suse.de>]

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.

-- 
Jens Axboe