From mboxrd@z Thu Jan  1 00:00:00 1970
From: jens.axboe@oracle.com (Jens Axboe)
Date: Mon, 19 Jan 2009 19:23:37 +0100
Subject: [ltt-dev] [RFC PATCH] block: Fix bio merge induced high I/O
	latency
In-Reply-To: <807b3a220901190745w79827b41u1cc9045a2ac268e5@mail.gmail.com>
References: <20090117004439.GA11492@Krystal> <20090117162657.GA31965@Krystal>
	<20090117190437.GZ30821@kernel.dk>
	<807b3a220901190745w79827b41u1cc9045a2ac268e5@mail.gmail.com>
Message-ID: <20090119182336.GS30821@kernel.dk>

On Mon, Jan 19 2009, Nikanth K wrote:
> On Sun, Jan 18, 2009 at 12:34 AM, Jens Axboe <jens.axboe at oracle.com> wrote:
> 
> >
> > As a quick test, could you try and increase the slice_idle to eg 20ms?
> > Sometimes I've seen timing being slightly off, which makes us miss the
> > sync window for the ls (in your case) process. Then you get a mix of
> > async and sync IO all the time, which very much slows down the sync
> > process.
> >
> 
> Do you mean to say that 'ls' could not submit another request until
> the previous sync request completes, but its idle window gets disabled
> as it takes way too long to complete during heavy load? But when there

'ls' would never submit a new request before the previous one completes,
such is the nature of sync processes. That's the whole reason we have
the idle window.

> are requests in the driver, wont the idling be disabled anyway? Or did
> you mean to increase slice_sync?

No, idling is on a per-cfqq (process) basis. I did not mean to increase
slice_sync, that wont help at all. It's the window between submissions
of requests that I wanted to test being larger, but apparently that
wasn't the case here.

-- 
Jens Axboe