From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 5 Aug 2005 01:40:25 +0200 From: Andi Kleen Subject: Re: NUMA policy interface Message-ID: <20050804234025.GJ8266@wotan.suse.de> References: <20050803084849.GB10895@wotan.suse.de> <20050804142942.GY8266@wotan.suse.de> <20050804170803.GB8266@wotan.suse.de> <20050804211445.GE8266@wotan.suse.de> <20050804214132.GF8266@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Andi Kleen , Paul Jackson , linux-kernel@vger.kernel.org, linux-mm@kvack.org List-ID: On Thu, Aug 04, 2005 at 03:19:52PM -0700, Christoph Lameter wrote: > There are three possibilites: > > 1. do what cpusets is doing by versioning. > > 2. Have the task notifier access the task_struct information. > See http://lwn.net/Articles/145232/ "A new path to the refrigerator" > > 3. Maybe the easiest: Require mmap_sem to be taken for all policy > accesses. Currently its only require for vma policies. Then we need > to make a copy of the policy at some point so that alloc_pages can > access policy information lock free. This may also allow us to fix > the bind issue if we would f.e. keep a bitmap in the taskstruct or (ab)use > the cpusets map. None of them seem very attractive to me. I would prefer to just not support external accesses keeping things lean and fast. > > If they cannot afford enough disk space it might be possible > > to do the page migration in swap cache like Hugh proposed. > > This code already exist in the memory hotplug code base and Ray already > had a working implementation for page migration. The migration code will > also be necessary in order to relocate pages with ECC single bit failures > that Russ is working on (of course that will only work for some pages) and > for Mel Gorman's defragmentation approach (if we ever get the split into > differnet types of memory chunks in). Individual physical page migration is quite different from address space migration. -Andi -- 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: email@kvack.org