linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Paul Jackson <pj@sgi.com>
Cc: nickpiggin@yahoo.com.au, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, akpm@osdl.org, ck@vds.kolivas.org
Subject: Re: [PATCH] mm: implement swap prefetching
Date: Wed, 8 Feb 2006 16:06:19 +1100	[thread overview]
Message-ID: <200602081606.19656.kernel@kolivas.org> (raw)
In-Reply-To: <20060207204655.f1c69875.pj@sgi.com>

On Wed, 8 Feb 2006 03:46 pm, Paul Jackson wrote:
> Con, responding to Nick:
> > > It introduces global cacheline bouncing in pagecache allocation and
> > > removal and page reclaim paths, also low watermark failure is quite
> > > common in normal operation, so that is another global cacheline write
> > > in page allocation path.
> >
> > None of these issues is going to remotely the target audience. If the
> > issue is how scalable such a change can be then I cannot advocate making
> > the code smart and complex enough to be numa and cpuset aware.. but then
> > that's never going to be the target audience. It affects a particular
> > class of user which happens to be quite a large population not affected
> > by complex memory hardware.
>
> How about only moving memory back to the Memory Node (zone) that it
> came from?  And providing some call that Christoph Lameters migration
> code can call, to disable or fix this up, so you don't end up bringing
> back pages on their pre-migration nodes?

Sounds good, and this is what I was hoping to be able to do; first I need to 
see the best time and place to get this information (and learn some more 
about the code).

> Just honoring the memory node placement should be sufficient.  No need
> to wrap your head around cpusets.

Phew. 

> If you don't do that, then consider disabling this thing entirely
> if CONFIG_NUMA is enabled.  This swap prefetching sounds like it
> could be a loose canon ball in a NUMA box.

That's probably a less satisfactory option since NUMA isn't that rare with the 
light numa of commodity hardware.

> As for non-NUMA boxes, like my humble desktop PC, I would -love-
> to have Firefox come back up faster in the morning.  I have a nightly
> cron jobs push everything out to swap, and it is slow going getting it
> back.
>
> The day will come (it has already gotten there for some of my
> colleagues who are using a small Altix system for their desktop
> software) when we want this prefetching for NUMA boxes too.

I do see that now. Thanks for your comments too.

Cheers,
Con

--
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:[~2006-02-08  5:06 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-06 23:28 Con Kolivas
2006-02-07  0:38 ` Andrew Morton
2006-02-07  1:29   ` Con Kolivas
2006-02-07  1:32     ` [ck] " Con Kolivas
2006-02-07  1:39     ` Andrew Morton
2006-02-08  3:29   ` [PATCH] mm: implement swap prefetching v21 Con Kolivas
2006-02-08  3:49     ` [ck] " Con Kolivas
2006-02-07  3:08 ` [PATCH] mm: implement swap prefetching Nick Piggin
2006-02-07  3:29   ` Nick Piggin
2006-02-07  4:02   ` Con Kolivas
2006-02-07  5:00     ` Nick Piggin
2006-02-07  6:02       ` Con Kolivas
2006-02-07  6:51         ` Nick Piggin
2006-02-07 10:54           ` Con Kolivas
2006-02-07 17:14             ` Andrew Morton
2006-02-07 20:34           ` Marcelo Tosatti
2006-02-07 22:39             ` Andi Kleen
2006-02-08  4:46     ` Paul Jackson
2006-02-08  5:06       ` Con Kolivas [this message]
2006-02-08  5:13         ` Paul Jackson
2006-02-08  5:33         ` Con Kolivas
2006-02-24 11:23 [PATCH] mm: Implement " Con Kolivas

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=200602081606.19656.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=akpm@osdl.org \
    --cc=ck@vds.kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=pj@sgi.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