From: Mel Gorman <mel@csn.ul.ie>
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Mel Gorman <mel@skynet.ie>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <clameter@sgi.com>,
linux-mm@kvack.org, ak@suse.de, mtk-manpages@gmx.net,
solo@google.com, eric.whitney@hp.com
Subject: Re: [PATCH/RFC 0/5] Memory Policy Cleanups and Enhancements
Date: Fri, 14 Sep 2007 18:46:07 +0100 [thread overview]
Message-ID: <1189791967.13629.24.camel@localhost> (raw)
In-Reply-To: <1189782414.5315.36.camel@localhost>
On Fri, 2007-09-14 at 11:06 -0400, Lee Schermerhorn wrote:
> On Fri, 2007-09-14 at 09:53 +0100, Mel Gorman wrote:
> > On (13/09/07 14:17), Andrew Morton didst pronounce:
> > > On Thu, 13 Sep 2007 11:26:19 -0700 (PDT)
> > > Christoph Lameter <clameter@sgi.com> wrote:
> > >
> > > > On Thu, 13 Sep 2007, Mel Gorman wrote:
> > > >
> > > > > What do you see holding it up? Is it the fact we are no longer doing the
> > > > > pointer packing and you don't want that structure to exist, or is it simply
> > > > > a case that 2.6.23 is too close the door and it won't get adequate
> > > > > coverage in -mm?
> > > >
> > > > No its not the pointer packing. The problem is that the patches have not
> > > > been merged yet and 2.6.23 is close. We would need to merge it very soon
> > > > and get some exposure in mm. Andrew?
> > >
> > > You rang?
> > >
> > > To which patches do you refer? "Memory Policy Cleanups and Enhancements"?
> > > That's still in my queue somewhere, but a) it has "RFC" in it which usually
> > > makes me run away and b) we already have no fewer than 221 memory
> > > management patches queued.
> > >
> >
> > Christoph's question is in relation to the patchset "Use one zonelist per
> > node instead of multiple zonelists v7" and whether one zonelist will be
> > merged in 2.6.24 in your opinion. I am hoping "yes" because it removes that
> > hack with ZONE_MOVABLE and policies. I had sent you a version (v5) but there
> > were further suggestions on ways to improve it so we're up to v7 now. Lee
> > will hopefully be able to determine if v7 regresses policy behaviour or not.
> >
>
> Hi, Mel:
>
> I'm running with your patches now. An earlier version--just received v7
> end of day yesterday. Will rebuild today. I've been using the kernel
> with your patches for general patch development and kernel building on
> my ia64 numa platform. Before I rebooted to test another kernel
> [reclaim scalability/noreclaim patch set], your mail prompted me to try
> a couple of memtoy migration scripts. I managed to hang/panic the
> system with a null pointer deref and a very interesting stack trace,
> which I didn't capture [want to test w/ v7].
Very uncool. If I am null dereferencing anywhere, it's going to be in
the iterator so check for get_page_from_freelist() in the stack.
> The trace included some
> kprobes functions--which I'm not using--and a lot of tcp/network stack
> routines. I have no clue whether these are related to your patches.
> The hang that I experienced before the panic could have been a local
> site network glitch [happens, sometimes] that triggered a fault in the
> network stack.
>
How bizarre.
> Again, I'll retest with the v7 patches today. In the meantime, you
> might want to grab memtoy from:
> http://free.linux.hp.com/~lts/Tools/memtoy-latest.tar.gz
> and try out the test scripts in the Xpm-tests/Mbind directory. Note
> that these scripts assume a 4-node numa system, but from the comments
> you should be able to mod them for whatever numa system you have
> available. Building memtoy can also be a bit of a challenge, depending
> on your environment--no autoconfig or such. Check out the README for
> instructions/caveats/...
>
Ok, I'll give it a shot and see how I get on. Thanks Lee
--
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:[~2007-09-14 17:46 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-30 18:50 [PATCH/RFC 0/5] Memory Policy Cleanups and Enhancements Lee Schermerhorn
2007-08-30 18:51 ` [PATCH/RFC 1/5] Mem Policy: fix reference counting Lee Schermerhorn
2007-09-11 18:48 ` Mel Gorman
2007-09-11 18:12 ` Lee Schermerhorn
2007-09-13 9:45 ` Mel Gorman
2007-08-30 18:51 ` [PATCH/RFC 2/5] Mem Policy: Use MPOL_PREFERRED for system-wide default policy Lee Schermerhorn
2007-09-11 18:54 ` Mel Gorman
2007-09-11 18:22 ` Lee Schermerhorn
2007-09-13 9:48 ` Mel Gorman
2007-08-30 18:51 ` [PATCH/RFC 3/5] Mem Policy: MPOL_PREFERRED fixups for "local allocation" Lee Schermerhorn
2007-09-11 18:58 ` Mel Gorman
2007-09-11 18:34 ` Lee Schermerhorn
2007-09-12 22:10 ` Christoph Lameter
2007-09-13 13:51 ` Lee Schermerhorn
2007-09-13 18:18 ` Christoph Lameter
2007-09-13 9:55 ` Mel Gorman
2007-09-12 22:06 ` Christoph Lameter
2007-09-13 13:35 ` Lee Schermerhorn
2007-09-13 18:21 ` Christoph Lameter
2007-08-30 18:51 ` [PATCH/RFC 4/5] Mem Policy: cpuset-independent interleave policy Lee Schermerhorn
2007-09-12 21:20 ` Ethan Solomita
2007-09-12 22:14 ` Christoph Lameter
2007-09-13 13:26 ` Lee Schermerhorn
2007-09-13 17:17 ` Ethan Solomita
2007-09-12 21:59 ` Ethan Solomita
2007-09-13 13:32 ` Lee Schermerhorn
2007-09-13 17:19 ` Ethan Solomita
2007-09-13 18:20 ` Christoph Lameter
2007-10-09 6:15 ` Ethan Solomita
2007-10-09 13:39 ` Lee Schermerhorn
2007-10-09 18:49 ` Christoph Lameter
2007-10-09 19:02 ` Lee Schermerhorn
2007-08-30 18:51 ` [PATCH/RFC 5/5] Mem Policy: add MPOL_F_MEMS_ALLOWED get_mempolicy() flag Lee Schermerhorn
2007-09-11 19:07 ` Mel Gorman
2007-09-11 18:42 ` Lee Schermerhorn
2007-09-12 22:14 ` Christoph Lameter
2007-09-14 20:24 ` [PATCH] " Lee Schermerhorn
2007-09-14 20:27 ` Christoph Lameter
2007-09-11 16:20 ` [PATCH/RFC 0/5] Memory Policy Cleanups and Enhancements Lee Schermerhorn
2007-09-11 19:12 ` Mel Gorman
2007-09-11 18:45 ` Lee Schermerhorn
2007-09-12 22:17 ` Christoph Lameter
2007-09-13 13:57 ` Lee Schermerhorn
2007-09-13 15:31 ` Mel Gorman
2007-09-13 15:01 ` Lee Schermerhorn
2007-09-13 18:55 ` Mel Gorman
2007-09-13 18:19 ` Christoph Lameter
2007-09-13 18:23 ` Mel Gorman
2007-09-13 18:26 ` Christoph Lameter
2007-09-13 21:17 ` Andrew Morton
2007-09-14 2:20 ` Christoph Lameter
2007-09-14 8:53 ` Mel Gorman
2007-09-14 15:06 ` Lee Schermerhorn
2007-09-14 17:46 ` Mel Gorman [this message]
2007-09-14 18:41 ` Christoph Lameter
2007-09-16 18:02 ` Mel Gorman
2007-09-17 18:12 ` Christoph Lameter
2007-09-17 18:19 ` Christoph Lameter
2007-09-17 20:14 ` Mel Gorman
2007-09-17 19:16 ` Christoph Lameter
2007-09-17 20:03 ` Mel Gorman
2007-09-14 20:15 ` Lee Schermerhorn
2007-09-16 18:05 ` Mel Gorman
2007-09-16 19:34 ` Andrew Morton
2007-09-16 21:22 ` Mel Gorman
2007-09-17 13:29 ` Lee Schermerhorn
2007-09-17 18:14 ` Christoph Lameter
2007-09-13 15:49 ` Lee Schermerhorn
2007-09-13 18:22 ` Christoph Lameter
2007-09-17 19:00 ` [PATCH] Fix NUMA Memory Policy Reference Counting Lee Schermerhorn
2007-09-17 19:14 ` Christoph Lameter
2007-09-17 19:38 ` Lee Schermerhorn
2007-09-17 19:43 ` Christoph Lameter
2007-09-19 22:03 ` Lee Schermerhorn
2007-09-19 22:23 ` Christoph Lameter
2007-09-18 10:36 ` Mel Gorman
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=1189791967.13629.24.camel@localhost \
--to=mel@csn.ul.ie \
--cc=Lee.Schermerhorn@hp.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=eric.whitney@hp.com \
--cc=linux-mm@kvack.org \
--cc=mel@skynet.ie \
--cc=mtk-manpages@gmx.net \
--cc=solo@google.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;
as well as URLs for NNTP newsgroup(s).