Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261570AbVBOBTd (ORCPT ); Mon, 14 Feb 2005 20:19:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261586AbVBOBQt (ORCPT ); Mon, 14 Feb 2005 20:16:49 -0500 Received: from gateway-1237.mvista.com ([12.44.186.158]:33014 "EHLO av.mvista.com") by vger.kernel.org with ESMTP id S261584AbVBOBCw (ORCPT ); Mon, 14 Feb 2005 20:02:52 -0500 Message-ID: <42114A1F.5070202@mvista.com> Date: Mon, 14 Feb 2005 17:02:23 -0800 From: Steve Longerbeam User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: Robin Holt , Ray Bryant , Ray Bryant , linux-mm , linux-kernel Subject: Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview References: <20050212032535.18524.12046.26397@tomahawk.engr.sgi.com> <20050212121228.GA15340@lnx-holt.americas.sgi.com> <20050214191840.GA57423@muc.de> In-Reply-To: <20050214191840.GA57423@muc.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1701 Lines: 42 Andi Kleen wrote: >>For our use, the batch scheduler will give an intermediary program a >>list of processes and a series of from-to node pairs. That process would >>then ensure all the processes are stopped, scan their VMAs to determine >>what regions are mapped by more than one process, which are mapped >>by additional processes not in the job, and make this system call for >>each of the unique ranges in the job to migrate their pages from one >>node to the next. I believe Ray is working on a library and a standalone >>program to do this from a command line. >> >> > >Sounds quite ugly. > >Do you have evidence that this is a common use case? (jobs having stuff >mapped from programs not in the job). If not I think it's better >to go with a simple interface, not one that is unusable without >a complex user space library. > >If you mean glibc etc. only then the best solution for that would be probably >to use the (currently unmerged) arbitary file mempolicy code for this and set > a suitable attribute that prevents moving. > > Hi Andi, Ray, et.al., Just want to let you know that I'm still planning to push my patches to NUMA mempolicy for filemap support and page migration. I've been swamped with another task at work, but later this week I will post the latest patches for review. I haven't been following Ray's manual page migration thread but will get up-to-speed also, and see how it impacts my patchset to mempolicy. Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/