All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Natalie Protasevich" <protasnb@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Rik van Riel <riel@redhat.com>, mel@skynet.ie, linux-mm@kvack.org
Subject: Re: bug #5493
Date: Thu, 8 Nov 2007 20:52:01 -0800	[thread overview]
Message-ID: <32209efe0711082052wbb3376i324729d41c5ecd3d@mail.gmail.com> (raw)
In-Reply-To: <20071108202707.d7efed57.akpm@linux-foundation.org>

On Nov 8, 2007 8:27 PM, 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.
>
> > I might use this test case to play with the SEQ replacement
> > of anonymous pages.  Figuring out how to avoid some worst
> > case that people really hit in practice is often educational.
>
> I don't think we can anywhere near fix this without basic redesign of VM
> data structures and the relationship between them.
>

So,  Solaris (open?) has really really different VM design the I suppose?

--
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>

  reply	other threads:[~2007-11-09  4:52 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 ` bug #5493 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 [this message]
2007-11-09 15:09               ` Rik van Riel

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=32209efe0711082052wbb3376i324729d41c5ecd3d@mail.gmail.com \
    --to=protasnb@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@skynet.ie \
    --cc=riel@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.