On Wed, 21 Feb 2001, Jens Axboe wrote:
> On Tue, Feb 20 2001, Chaitanya Tumuluri wrote:
> > True. So, how about trying out the following patch which is a
> > first cut at inserting the kiobuf requests in LBA-ordered
> > fashion in the elevator?
> >
> > At the very least, it reduces the seek times which might've been
> > affecting kiobuf I/O performance adversely.
>
> You just further extend what I really don't like about the
> current approach to kiobuf I/O ;-). It's on huge clamp-on
> to ll_rw_blk...
Hi,
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.
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. :^)
> 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.
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.
>BTW, the max_segments is gone from the current tree.
Ooooh! kiobuf-sized buffer-head requests are now allowed? Cool! :^)
Thanks for the heads-up.
Cheers,
-Chait.
|