On Wed, Feb 21, 2001 at 02:27:00AM +0100, Jens Axboe wrote:
> 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
Just there seem to be lots of drivers that cannot deal with big requests.
-Andi
|