LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Paul Jackson <pj@sgi.com>
Cc: akpm@linux-foundation.org, clameter@sgi.com,
	Lee.Schermerhorn@hp.com, ak@suse.de,
	linux-kernel@vger.kernel.org
Subject: Re: [patch 5/6] mempolicy: add MPOL_F_RELATIVE_NODES flag
Date: Tue, 26 Feb 2008 13:17:55 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.1.00.0802261306110.10790@chino.kir.corp.google.com> (raw)
In-Reply-To: <20080226114417.c8948b61.pj@sgi.com>

On Tue, 26 Feb 2008, Paul Jackson wrote:

> Perhaps I missed it, but could you elaborate on what sort of testing
> these patches for MPOL_F_RELATIVE_NODES and MPOL_F_STATIC_NODES have
> received?
> 

Both MPOL_F_STATIC_NODES and MPOL_F_RELATIVE_NODES only really change the 
implementation when a new mempolicy is created and on rebind.

So it's possible to test both of these areas by booting with numa=fake=8, 
setting up a cpuset, hacking numactl to allow |static or |relative options 
to be passed, changing the cpuset's mems, and checking the result.  Then 
you can repeat that process with a different set of initial cpuset mems 
and a different syscall nodemask.

	# mount -t cpuset none /dev/cpuset
	# mkdir /dev/cpuset/test
	# cd /dev/cpuset/test
	# echo 0-3 > cpus
	# echo 1-3 > mems
	# echo $$ > tasks
	# numactl --interleave|static=2-4 bash
	# numactl --show
	[should be interleave over 2-3]
	# echo 4-6 > mems
	[should be "interleave" over 4]
	# numactl --show

> In particular, do we know that Oracle works with this?  At least in
> years past, when Andi was the primary developer here, he had some
> good and detailed awareness of what it took to keep Oracle happy
> with this NUMA memory policy apparatus.  I don't know if we still
> have that awareness.
> 

I don't understand what Oracle has to do with anything here, it is up to 
the programmer to determine whether he wants to use MPOL_F_STATIC_NODES or 
MPOL_F_RELATIVE_NODES for the benefit of his or her application.  There's 
now a method for doing that, specifically with optional mempolicy mode 
flags.

If you have any examples of unexpected behavior after applying my 
patchset, please post it and I'll fix it rather quickly.

		David

  reply	other threads:[~2008-02-26 21:18 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-25 15:35 [patch 1/6] mempolicy: convert MPOL constants to enum David Rientjes
2008-02-25 15:35 ` [patch 2/6] mempolicy: support optional mode flags David Rientjes
2008-02-25 15:35   ` [patch 3/6] mempolicy: add MPOL_F_STATIC_NODES flag David Rientjes
2008-02-25 15:35     ` [patch 4/6] mempolicy: add bitmap_onto() and bitmap_fold() operations David Rientjes
2008-02-25 15:35       ` [patch 5/6] mempolicy: add MPOL_F_RELATIVE_NODES flag David Rientjes
2008-02-25 15:35         ` [patch 6/6] mempolicy: update NUMA memory policy documentation David Rientjes
2008-02-26 17:34           ` Paul Jackson
2008-02-26 21:23             ` David Rientjes
2008-02-26  6:12         ` [patch 5/6] mempolicy: add MPOL_F_RELATIVE_NODES flag Paul Jackson
2008-02-26  6:45           ` David Rientjes
2008-02-26 17:44         ` Paul Jackson
2008-02-26 21:17           ` David Rientjes [this message]
2008-02-26 21:30             ` Paul Jackson
2008-02-26 21:27           ` Lee Schermerhorn
2008-02-27  1:17         ` David Rientjes
2008-02-27  1:31           ` David Rientjes
2008-02-27  2:30           ` Paul Jackson
2008-02-27 15:37           ` Lee Schermerhorn
2008-02-27 17:09             ` Paul Jackson
2008-02-28 21:08             ` David Rientjes
2008-02-26  5:46     ` [patch 3/6] mempolicy: add MPOL_F_STATIC_NODES flag Paul Jackson
2008-02-26  6:53       ` David Rientjes
2008-02-26 17:56     ` Paul Jackson
2008-02-26 21:02       ` David Rientjes
2008-02-26 21:32         ` Lee Schermerhorn
2008-02-26 21:54           ` David Rientjes
2008-02-26 22:08             ` Paul Jackson
2008-02-26 21:39         ` Paul Jackson
2008-02-26  3:20 ` [patch 1/6] mempolicy: convert MPOL constants to enum Paul Jackson
2008-02-26  3:35   ` David Rientjes
2008-02-26  4:02     ` Paul Jackson
2008-02-26  4:21       ` David Rientjes
2008-02-26  4:46         ` Paul Jackson
2008-02-27 19:35 ` Christoph Lameter
2008-02-27 19:59   ` David Rientjes
2008-03-01  0:44 David Rientjes
2008-03-01  0:45 ` [patch 2/6] mempolicy: support optional mode flags David Rientjes
2008-03-01  0:45   ` [patch 3/6] mempolicy: add MPOL_F_STATIC_NODES flag David Rientjes
2008-03-01  0:45     ` [patch 4/6] mempolicy: add bitmap_onto() and bitmap_fold() operations David Rientjes
2008-03-01  0:45       ` [patch 5/6] mempolicy: add MPOL_F_RELATIVE_NODES flag David Rientjes

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=alpine.DEB.1.00.0802261306110.10790@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).