Re: Page aging broken in 2.6

[Andrew Morton]

Roger Luethi <rl@xxxxxxxxxxx> wrote:
>
> On Fri, 26 Dec 2003 19:00:45 -0800, Andrew Morton wrote:
> > The current behaviour seems better from a theoretical point of view.  All
> > we want to know is the reference pattern - whether it is one process
> > referencing the page frequently or 100 processes referencing it
> > infrequently shouldn't matter.  And if we want to give mapped pages more
> 
> It can matter. Evicting a page that is infrequently referenced by many
> processes increases the chance that all runnable processes block waiting
> for that same page later. The likelihood of that happening grows under
> memory pressure, when "infrequently" may actually be "quite often" and
> when disk I/O is congested (resulting in higher disk access times).
> 
> You won't have the same effect when evicting a page that is referenced
> by one process only, no matter how frequently.
> 
> Having all processes blocked is indeed one problem of 2.6 under memory
> pressure. I don't know what the cause is, though.
> 

I usually work this sort of thing out by "random sampling".  When
everything is in steady state, break into kgdb and start looking at task
backtraces, see where they are all sleeping.

If it's in the pagefault handler, go up to do_page_fault() and work out the
faulting address.  Compare that with /proc/pid/maps to see if it's libc or
whatever.

Repeat the above N times until you have a decent feel for what's happening
in there.  It doesn't take long.

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