> On Tue, Mar 28, 2000 at 05:37:53PM -0600, Jim Mostek wrote:
> >
> >
> > has been updated 3/28/2000. Comments would be greatly appreciated.
>
> It includes porting of GRIO. At what layer do you expect it to sit
> (above or below or instead of ll_rw_blk) ?
>
>
> -Andi
The answer is probably to replace ll_rw_blk and the driver interface with
something else.
The GRIO kernel component throttles the I/O to devices, a user space component
manages a reservation system.
ll_rw_blk and GRIO probably do not sit well together. The GRIO code wants
explicit control over when I/O starts - and the I/O which it wants to start
will be the whole of the user's request (GRIO is specific to O_DIRECT I/O,
data should be transferred directly from user memory to the disk).
The fixed request size imposed by ll_rw_blk rather gets in the way of this,
in fact it gets in the way of XFS in general which needs to do 512 byte
I/Os for some meta-data, but can really take advantage of larger requests.
The CPU overhead of breaking larger requests into bits and then relying on
make_request to reassemble them can be big. run_task_queue(&tq_disk) is also
a bit of a sledgehammer once you have lots of disks doing I/O, at a minimum
this could do with breaking up into a per-filesystem/device wake up.
We have lots of other fish to fry before we get to GRIO.
Steve
|