Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753491Ab2JUMaQ (ORCPT ); Sun, 21 Oct 2012 08:30:16 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:65376 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753228Ab2JUMaO (ORCPT ); Sun, 21 Oct 2012 08:30:14 -0400 Date: Sun, 21 Oct 2012 14:30:08 +0200 From: Ingo Molnar To: Rik van Riel Cc: Peter Zijlstra , Andrea Arcangeli , Linux Memory Management List , Mel Gorman , Thomas Gleixner , Linux kernel Mailing List Subject: Re: question on NUMA page migration Message-ID: <20121021123008.GA19229@gmail.com> References: <5081777A.8050104@redhat.com> <1350664742.2768.40.camel@twins> <50818A41.7030909@redhat.com> <1350669236.2768.66.camel@twins> <50819CED.30803@redhat.com> <20121020012345.GA24667@gmail.com> <5082CB18.6060300@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5082CB18.6060300@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2920 Lines: 85 * Rik van Riel wrote: > On 10/19/2012 09:23 PM, Ingo Molnar wrote: > > > >* Rik van Riel wrote: > > > >>On 10/19/2012 01:53 PM, Peter Zijlstra wrote: > >>>On Fri, 2012-10-19 at 13:13 -0400, Rik van Riel wrote: > >> > >>>>Another alternative might be to do the put_page inside > >>>>do_prot_none_numa(). That would be analogous to do_wp_page > >>>>disposing of the old page for the caller. > >>> > >>>It'd have to be inside migrate_misplaced_page(), can't do before > >>>isolate_lru_page() or the page might disappear. Doing it after is > >>>(obviously) too late. > >> > >>Keeping an extra refcount on the page might _still_ > >>result in it disappearing from the process by some > >>other means, in-between you grabbing the refcount > >>and invoking migration of the page. > >> > >>>>I am not real happy about NUMA migration introducing its own > >>>>migration mode... > >>> > >>>You didn't seem to mind too much earlier, but I can remove it if you > >>>want. > >> > >>Could have been reviewing fatigue :) > > > >:-) > > > >>And yes, it would have been nice to not have a special > >>migration mode for sched/numa. > >> > >>Speaking of, when do you guys plan to submit a (cleaned up) > >>version of the sched/numa patch series for review on lkml? > > > >Which commit(s) worry you specifically? > > One of them would be the commit that introduces MIGRATE_FAULT. MIGRATE_FAULT is still used. > Adding it in one patch, and removing it into a next just makes > things harder on the reviewers. Yes. > 03a040f6c17ab81659579ba6abe267c0562097e4 It's still used: comet:~/tip> git grep MIGRATE_FAULT include/linux/migrate_mode.h: * MIGRATE_FAULT called from the fault path to migrate-on-fault for mempolicy include/linux/migrate_mode.h: MIGRATE_FAULT, mm/migrate.c: if (mode != MIGRATE_ASYNC && mode != MIGRATE_FAULT) { mm/migrate.c: if (mode == MIGRATE_FAULT) { mm/migrate.c: * MIGRATE_FAULT has an extra reference on the page and mm/migrate.c: if ((mode == MIGRATE_ASYNC || mode == MIGRATE_FAULT) && head && mm/migrate.c: if (mode != MIGRATE_ASYNC && mode != MIGRATE_FAULT) mm/migrate.c: if (!force || mode == MIGRATE_ASYNC || mode == MIGRATE_FAULT) mm/migrate.c: ret = __unmap_and_move(page, newpage, 0, 0, MIGRATE_FAULT); > If the changesets with NUMA syscalls are still in your tree's > history, they should not be submitted as part of the patch > series, either. No, the syscalls have not been there for quite some time. If you have trouble with any specific commit, please quote the specific SHA1 so that I can have a look and resolve any specific concerns. Otherwise, lets continue with the integration? Thanks, Ingo -- 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/