On Tue, Feb 20 2001, Chaitanya Tumuluri wrote:
> Its not a "clamp-on"; its an alternative code-path that is
> being maintained as independantly as possible from the buffer-head
> path. Easy surgery being the motivation.
It is so much a clamp-on! Just look for all the
if (bh)
/* do bh stuff */
else
/* do kio stuff */
that is all over ll_rw_blk.c. I'm not blaming anyone, and of course
this will be removed once 2.5 hits. And of course I understand
SGI's general need for keeping SGI code separated makes
maintenance and kernel merges easier.
> Yes, the intrusions into __make_request() (if that is what you're
> actually referring to) are obvious. But, given the kiobuf data
> structure as it currently exists, I can't see any other alternative!
> If there are other alternatives (of which I think several are being
> implemented as I write this)...I'd love to see the actual code.
> I'm perfectly willing to trash the current implementation if there is
> a viable data-structure that permits it. :^)
Not just __make_request, but lots of other places. That's not
all I mean by being clamped on, interfaces have been extended
arbitrarily to support kiobuf stuff. But as I said, as the block
stuff grows in 2.5 we can support this much better.
> > How about something that doesn't do merges on kiobufs, but
> > just searches for an insertion point exactly like a buffer_head
> > would do? And please don't make elevator_merge_fn even bigger
> > than it already is, within limits of course.
>
> For starters, this patch does _NOT_ try to merge kiobufs.
For christ sake, calm down :-). Of course it doesn't, in fact
it would be quite a feat if you did that in that small a patch.
> Next, it _DOES_ try to find the insertion point for the kiobuf
> request in the device queue; based on the trying to find a
> request (bh or kiobuf) whose first sector aligns with the last
> sector of I/O in the incoming kiobuf.
Yeah I can read the code. And I guess you are right, for now
you will have to (again) make kiobuf special cases.
> >BTW, the max_segments is gone from the current tree.
>
> Ooooh! kiobuf-sized buffer-head requests are now allowed? Cool! :^)
They can grow arbitrarily big, only limited by limitations of the
low level driver. But the reason max_segments is gone is because
we don't actually need it for the merging anymore, if we can't
extend another segments we won't try to do merges anyway.
--
Jens Axboe
|