Re: bug #5493

Rik van Riel
2007-11-09T15:09:33Z

On Thu, 8 Nov 2007 20:27:07 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:

> > On Thu, 8 Nov 2007 20:00:41 -0500 Rik van Riel <riel@redhat.com> wrote:
> > On Thu, 8 Nov 2007 10:56:59 -0800
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> > > > On Thu, 8 Nov 2007 13:15:18 -0500 Rik van Riel <riel@redhat.com> wrote:
> > > > On Thu, 8 Nov 2007 09:57:04 -0800
> >
> > > > > No, it was due to linear traversal of very long reverse-mapping lists
> > > > > (thousands of elements, irrc).
> > > >
> > > > Traversal at pageout time, or at mprotect time?
> > > >
> > >
> > > pageout, iirc. For each page we were walking a linear list of I think
> > > ~10,000 elements.
> >
> > Pageout scan complexity in this workload is O(P*M), where
> > P is the number of pages scanned and M is the number of
> > mappings.
> >
> > My code will, in the next iteration, reduce P by a fair
> > amount for larger amounts of memory, but M is still very
> > large...
>
> That's yet to be proven - for the vast majority of workloads your P is
> already very small.

For the vast majority of workloads, yes.

However, all anonymous pages (which this workload fills
memory with) start out as referenced.

We will not start clearing those referenced bits until
all of memory fills up and we're reaching some level of
distress.

At that point, we clear the referenced bits of all of
memory before swapping out a single page, due to the
way referenced pages go back to the other end of the
active list.

That hurts a little on a 1GB system, but is deadly on
a 256GB system.

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan