On Sun, 19 Nov 2000 17:24:57 -0200, Marcelo Tosatti <marcelo@xxxxxxxxxxxxxxxx>
wrote:
>
>Chait, Jens, Martin,
>
Hi Marcelo,
Seeing as how no-one's replied as yet; lemme take a quick stab at a response.
>Currently, generic_make_request() function and the per request queue
>make_request_fn() operation implement buffer-head and kiobuf based IO.
>
>IMHO the block layer should handle different IO "methods" (kiobuf and
>buffer-head) with different code.
>
That was the way it was originally implemented in the test1 thro' test5 XFS
trees
with: ll_rw_kio() calling __make_kio_request()
a la: ll_rw_block() calling __make_request()
Then things changed from test8 on, where generic_make_request() was introduced
to
accomodate stackable drivers, which broke things severely for the kiobuf I/O
path.
>This way the code gets cleaner, more simple, and independant from
>each other.
Yes, that was the original intent of the separate codepaths. However, there were
three comments made (by Alan Cox, Eric Youngdale, Stephen Tweedie among
others),
when I had originally submitted the kiobuf I/O patch to the kernel mailing
lists:
1. develop code only as a prototype/proof-of-concept for the 2.4
timeframe,
2. reuse code as far as possible,
3. keep the footprint of the changes small (for 2.4).
Thus, I'd agree with your suggestions below for the 2.5 timeframe. Can it wait
till then, or do you see a need for it in the RAID implementation? As for LVM,
I think it'd be a fairly simple to rework the 2.4 code for the 2.5 kernel when
the split in the codepaths becomes more apparent. mkp/axboe ?
>Right now, I think the following should be done:
>
>- split request_queue_t->make_request_fn into kio_make_request_fn and
>bh_make_request_fn.
>
>- Add a flag to be passed in blk_init_queue to inform if the caller
>supports kiobuf based IO. If the flag is on, set req->kio_make_request_fn
>to __kio_make_request.
This would certainly entail touching/modifying a whole bunch of drivers in the
kernel source (since you are changing an API). See 3. above.
>- split __make_request into ll_kio_make_request and ll_bh_make_request (or
>whatever better name for the functions).
This results in fairly large amounts of code duplication, especially when the
kiobuf-I/O code path starts to do request merging in the elevator. See 2. above.
To the extent possible, the current implementation tries to reuse code common to
the bh and kiobuf codepath. It deviates only in initializing:
* req->buffer, req->current_nr_sectors, req->nr_segments
* req->kiobuf, req->bh, req->bhtail
via two separate functions: __blk_init_req_kio() and __blk_init_req_bh()
So, in a sense, this separation is there already.
>- split generic_make_request into kio_make_request and bh_make_request.
>ll_rw_block should use bh_make_request and ll_rw_kio should use
>kio_make_request.
>
>This way, LVM and RAID should have their own kio_make_request and
>bh_make_request separate functions.
With your changes above, the LVM/RAID codepath is *forced* to make the
separation,
while the current codepath doesn't preclude LVM/RAID from having these separate
functions, but doesn't _require_ the separation either. For now, I think its
better to keep the options open, no?
>Comments?
>
>I'm working on RAID1 code. I'm running dbench on a kiobuf mounted XFS
>filesystem over a raid1 array with 2 SCSI partitions for some time now
>(the code is not complete yet, though, and I want to solve the issue
>discussed above).
Cool! How is it working out?
Cheers,
-Chait.
|