linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: mel@skynet.ie, protasnb@gmail.com, linux-mm@kvack.org
Subject: Re: bug #5493
Date: Fri, 9 Nov 2007 10:09:33 -0500	[thread overview]
Message-ID: <20071109100933.18ad7a58@bree.surriel.com> (raw)
In-Reply-To: <20071108202707.d7efed57.akpm@linux-foundation.org>

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      parent reply	other threads:[~2007-11-09 15:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <32209efe0711071800v4bc0c62er7bc462f1891c9dcd@mail.gmail.com>
2007-11-08  3:12 ` Andrew Morton
2007-11-08 16:53   ` Mel Gorman
2007-11-08 17:57     ` Andrew Morton
2007-11-08 18:15       ` Rik van Riel
2007-11-08 18:56         ` Andrew Morton
2007-11-09  1:00           ` Rik van Riel
2007-11-09  4:27             ` Andrew Morton
2007-11-09  4:52               ` Natalie Protasevich
2007-11-09 15:09               ` Rik van Riel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071109100933.18ad7a58@bree.surriel.com \
    --to=riel@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@skynet.ie \
    --cc=protasnb@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox