From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH/RFC 0/8] numa - Migrate-on-Fault Date: Wed, 17 Nov 2010 19:10:16 +0200 Message-ID: <4CE40C78.7060509@redhat.com> References: <20101111194450.12535.12611.sendpatchset@zaphod.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20101111194450.12535.12611.sendpatchset@zaphod.localdomain> Sender: linux-numa-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Lee Schermerhorn Cc: linux-numa@vger.kernel.org, akpm@linux-foundation.org, Mel Gorman , cl@linux-foundation.org, Nick Piggin , Hugh Dickins , KOSAKI Motohiro , andi@firstfloor.org, David Rientjes , Andrea Arcangeli On 11/11/2010 09:44 PM, Lee Schermerhorn wrote: > This series of patches implements page migration in the fault path. > > !!! N.B., Need to consider iteraction with KSM and Transparent Huge > !!! Pages. > > The basic idea is that when a fault handler such as do_swap_page() > finds a cached page with zero mappings that is otherwise "stable"-- > e.g., no I/O in progress--this is a good opportunity to check whether the > page resides on the node indicated by the mempolicy in the current context. > > We only attempt to migrate when there are zero mappings because 1) we can > easily migrate the page--don't have to go through the effort of removing > all mappings and 2) default policy--a common case--can give different > answers from different tasks running on different nodes. Checking the > policy when there are zero mappings effectively implements a "first touch" > placement policy. A couple of kvm-related notes: - kvm page faults are significantly more expensive than ordinary page faults; this will affect the cost/benefit tradeoff - kvm faults go through get_user_pages_fast(), not the ordinary fault path. Will the code handle this? -- error compiling committee.c: too many arguments to function