LKML Archive on
help / color / mirror / Atom feed
From: Nick Piggin <>
To: Christoph Lameter <>
Cc: Linux Kernel Mailing List <>,
	Linux Memory Management List <>
Subject: Re: [patch] mm: NUMA replicated pagecache
Date: Thu, 15 Feb 2007 01:07:09 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Feb 14, 2007 at 10:57:00AM -0800, Christoph Lameter wrote:
> On Tue, 13 Feb 2007, Nick Piggin wrote:
> > Just tinkering around with this and got something working, so I'll see
> > if anyone else wants to try it.
> > 
> > Not proposing for inclusion, but I'd be interested in comments or results.
> We would be very interested in such a feature. We have another hack that 
> shows up to 40% performance improvements.
> > At the moment the code is a bit ugly, but it won't take much to make it a
> > completely standalone ~400 line module with just a handful of hooks into
> > the core mm. So if anyone really wants it, it could be quite realistic to
> > get into an includable form.
> Would be great but I am a bit skeptical regarding the locking and the 
> additonal overhead moving back and forth between replications and non 
> replicated page state.

Locking is obviously ugly now. It can get better.

Replicating at any possible opportunity is probably not a good idea for
a real system. We need hints from userspace and/or kernelspace heuristics.
I'm just trying to get the mechanism working, though.

> > At some point I did take a look at Dave Hansen's page replication patch for
> > ideas, but didn't get far because he was doing a per-inode scheme and I was
> > doing per-page. No judgments on which approach is better, but I feel this
> > per-page patch is quite neat.
> Definitely looks better.
> > - Would be nice to transfer master on reclaim. This should be quite easy,
> >   must transfer relevant flags, and only if !PagePrivate (which reclaim
> >   takes care of).
> Transfer master? Meaning you need to remove the replicated pages? Removing 
> of replicated pages should transfer reference bit?

Yeah, I want to keep a master page so that we can replicate pages with
priviate filesystem data. But in the case that the master is !PagePrivate,
we should be able to reclaim it without collapsing the replication.

> > - Should go nicely with lockless pagecache, but haven't merged them yet.
> When is that going to happen? Soon I hope?

I'll submit it again and see what happens.

  reply	other threads:[~2007-02-15  0:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-13  6:09 [patch] mm: NUMA replicated pagecache Nick Piggin
2007-02-13  6:09 ` Nick Piggin
2007-02-14  4:28 ` Nick Piggin
2007-02-14 18:57 ` Christoph Lameter
2007-02-15  0:07   ` Nick Piggin [this message]
2007-02-14 19:00 ` Christoph Lameter
2007-02-15  0:10   ` Nick Piggin
2007-02-15  0:13     ` Christoph Lameter
2007-02-14 20:32 ` Lee Schermerhorn
2007-02-15  0:38   ` Nick Piggin
2007-02-15 23:29     ` Lee Schermerhorn
2007-02-16 13:35       ` Nick Piggin

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:

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

  git send-email \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).