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
WARNING: multiple messages have this Message-ID (diff)
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>
next prev parent reply other threads:[~2006-02-08 5:05 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-06 23:28 [PATCH] mm: implement swap prefetching Con Kolivas
2006-02-06 23:28 ` Con Kolivas
2006-02-07 0:38 ` Andrew Morton
2006-02-07 0:38 ` Andrew Morton
2006-02-07 1:29 ` Con Kolivas
2006-02-07 1:29 ` Con Kolivas
2006-02-07 1:32 ` [ck] " Con Kolivas
2006-02-07 1:32 ` Con Kolivas
2006-02-07 1:39 ` Andrew Morton
2006-02-07 1:39 ` Andrew Morton
2006-02-07 1:37 ` Bernd Eckenfels
2006-02-08 3:29 ` [PATCH] mm: implement swap prefetching v21 Con Kolivas
2006-02-08 3:49 ` [ck] " Con Kolivas
2006-02-08 3:49 ` Con Kolivas
2006-02-07 3:08 ` [PATCH] mm: implement swap prefetching Nick Piggin
2006-02-07 3:08 ` Nick Piggin
2006-02-07 3:29 ` Nick Piggin
2006-02-07 3:29 ` Nick Piggin
2006-02-07 4:02 ` Con Kolivas
2006-02-07 4:02 ` Con Kolivas
2006-02-07 5:00 ` Nick Piggin
2006-02-07 5:00 ` Nick Piggin
2006-02-07 6:02 ` Con Kolivas
2006-02-07 6:02 ` Con Kolivas
2006-02-07 6:51 ` Nick Piggin
2006-02-07 6:51 ` Nick Piggin
2006-02-07 10:54 ` Con Kolivas
2006-02-07 10:54 ` Con Kolivas
2006-02-07 17:14 ` Andrew Morton
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 4:46 ` Paul Jackson
2006-02-08 5:06 ` Con Kolivas [this message]
2006-02-08 5:06 ` Con Kolivas
2006-02-08 5:13 ` Paul Jackson
2006-02-08 5:13 ` Paul Jackson
2006-02-08 5:33 ` Con Kolivas
2006-02-08 5:33 ` Con Kolivas
-- strict thread matches above, loose matches on Subject: below --
2006-02-20 13:44 [PATCH] mm: Implement " Con Kolivas
2006-02-20 19:08 ` Mattia Dongili
2006-02-20 20:47 ` Con Kolivas
2006-02-20 20:58 ` Con Kolivas
2006-02-20 23:45 ` Michal Piotrowski
2006-02-24 11:23 Con Kolivas
2006-02-24 11:23 ` 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 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.