Re: PS/2 Esdi patch #8

[Jens Axboe <axboe@suse.de>]

On Sat, May 26 2001, A Duston wrote:
> >  and so it continues. This is the easy way to process requests. However,
> >  if you can start I/O on more than one buffer at the time (scatter
> >  gather), you could then setup your sg tables by browsing the entire
> >  request buffer_head list and initiate I/O as needed.
> >
> >  Bigger requests on the queue, means more I/O in progress being possible.
> >  There's no rule that you have to finish a request in one go, so even if
> >  you can only handle eg 64 sectors per request with sg, you could do
> >  just start I/O on as many segments as you can and simply don't dequeue
> >  the request until it's completely done. So the max_sectors patch is
> >  never really needed if you know what you are doing.
> 
> Can I still gain any advantage if the hardware can only have one I/O inflight
> per device?  I am not sure the ps2esdi interface supports this.

Not really, and especially for a slow interface like ps2esdi :-)

There's a small optimization possible for ps2esdi I see, but the chance
of it happening in real life is probably pretty slim. Even if you can't
do sg and you can't have more than one command pending, you could still
be lucky and do I/O to more than ->buffer provided that bh1 and bh2 etc
are contigous in memory. For a 4kB fs the chances are close to 0 that
this will happen once the system has been up for a little while (and
memory starts to fragment). For a 1kB fs the chances are probably
bigger.

If I were you, I'd leave it the way it is now. As long as you work on
current_nr_sectors, the only thing that Paul's patch will accomplish is
make the queue smaller. It will buy you nothing.

-- 
Jens Axboe