Re: cfq misbehaving on 2.6.11-1.14_FC3

[<spaminos-ker@yahoo.com>]

--- Andrew Morton <akpm@osdl.org> wrote:
> > For some reason, doing a "cp" or appending to files is very fast. I suspect
> > that vi's mmap calls are the reason for the latency problem.
> 
> Don't know.  Try to work out (from vmstat or diskstats) how much reading is
> going on.
> 
> Try stracing the check, see if your version of vi is doing a sync() or
> something odd like that.

The read/write patterns of the background process is about 35% reads.

vi is indeed doing a sync on the open file, and that's where the time was
spend.
So I just changed my test to simply opening a file, writing some data in it and
calling flush on the fd.

I also reduced the sleep to 1s instead of 1m, and here are the results:

cfq: 20,20,21,21,20,22,20,20,18,21 - avg 20.3
noop: 12,12,12,13,5,10,10,12,12,13 - avg 11.1
deadline: 16,9,16,14,10,6,8,8,15,9 - avg 11.1
as: 6,11,14,11,9,15,16,9,8,9 - avg 10.8

As you can see, cfq stands out (and it should stand out the other way).

> OK, well if the latency is mainly due to reads then one would hope that the
> anticipatory scheduler would do better than that.

I suspect the latency is due to writes: it seems (and correct me if I am wrong)
that write requests are enqueued in one giant queue, thus the cfq algorithm can
not be applied to the requests.

Either that, or there is a different queue that cancels out the benefits of cfq
when writing (because even though the writes are down the right way, this other
queue to the device keeps way too much data).

But then, why would other i/o schedulers perform better in that case?

> 
> But what happened to this, from your first report?
> 
> > On the other hand, opening a blank new file in vi and saving it takes about
> 5
> > minutes or so.
> 
> Are you able to reproduce that 5-minute stall in the more recent testing?
> 
> 
The most I got with this kernel, is a 1 minute stall, so there is improvement
there. Yet, a single process should not be able to cause this kind of stall
with cfq.

Nicolas


------------------------------------------------------------
video meliora proboque deteriora sequor
------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/