[Top] [All Lists]

Re: [Fwd: Re: mysterious dbench results]

To: Jens Axboe <axboe@xxxxxxx>
Subject: Re: [Fwd: Re: mysterious dbench results]
From: Chaitanya Tumuluri <chait@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 20 Feb 2001 16:54:15 -0500 (EST)
Cc: Thomas Graichen <graichen@xxxxxxxxxxxxx>, Rajagopal Ananthanarayanan <ananth@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <20010221013939.G1447@xxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
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...


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.


<Prev in Thread] Current Thread [Next in Thread>