[lkml]   [2001]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: i/o stalls on 2.4.14-pre3 with ext3
Linus Torvalds wrote:
> In article <>,
> Andrew Morton <> wrote:
> >
> >ext3's problem is that it is unable to react to VM pressure
> >for metadata (buffercache) pages. Once upon a time it did
> >do this, but we backed it out because it involved mauling
> >core kernel code. So at present we only react to VM pressure
> >for data pages.
> Note that the new VM has some support in place for the low-level
> filesystem reacting to VM pressure. In particular, one thing the fs can
> do is to look at the PG_launder bit (for pages) and PG_launder bit (for
> buffers), to figure out if the IO is due to memory pressure.

We don't get that far, unfortunately. ext3's problem is that the data
journalling (and its consequent ordering requirements) mean that a bare
try_to_free_buffers() will always fail, because we're holding elevated
refcounts against the buffers. This is why we added an a_op here. To
give the fs a chance to strip its stuff off the page before
try_to_free_buffers() has its try.

> There are two really silly request bugs in 2.4.14-pre3. I'd suggest
> trying pre5 which cleans up other things too, but even more notably
> should fix the request queue thinkos.

Hum. I did a quick test here. cvs checkout of a kernel
tree with source and dest both on the same platter. Using

2.4.13: 1:34
2.4.14-pre3: 1:28
2.4.14-pre5: 1:37

We need more silly bugs.

I'll poke at it a bit more. One perennial problem which
we face is that there isn't, IMO, a good set of tests for tracking
changes in thoughput. All the tools which are readily available
are good for stress testing and silly corner cases but they
don't seem to model real-world workloads well.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:18    [W:0.053 / U:1.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site