From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 16 Jul 2005 21:51:21 -0700 From: Paul Jackson Subject: Re: [NUMA] Display and modify the memory policy of a process through /proc//numa_policy Message-Id: <20050716215121.6c04ffb0.pj@sgi.com> In-Reply-To: References: <20050715214700.GJ15783@wotan.suse.de> <20050715220753.GK15783@wotan.suse.de> <20050715223756.GL15783@wotan.suse.de> <20050715225635.GM15783@wotan.suse.de> <20050715234402.GN15783@wotan.suse.de> <20050716020141.GO15783@wotan.suse.de> <20050716163030.0147b6ba.pj@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: ak@suse.de, kenneth.w.chen@intel.com, linux-mm@kvack.org, linux-ia64@vger.kernel.org List-ID: Christoph wrote: > Here is one approach to locking using xchg. What I see here doesn't change the behaviour of the kernel any - just adds some locked exchanges, right? I thought the hard part was having some other task change the current tasks mempolicy. For example, how does one task sync another tasks mempolicy up with its cpuset, or synchronously get the policies zonelist or preferred node set correctly? I guess that this approach is intended to show how to make it easy to add that hard part, right? ... whatever ... guess I'm still missing something ... -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.925.600.0401 -- 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: aart@kvack.org