lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 21 Oct 2012 14:30:08 +0200 From: Ingo Molnar <mingo@...nel.org> To: Rik van Riel <riel@...hat.com> Cc: Peter Zijlstra <peterz@...radead.org>, Andrea Arcangeli <aarcange@...hat.com>, Linux Memory Management List <linux-mm@...ck.org>, Mel Gorman <mel@....ul.ie>, Thomas Gleixner <tglx@...utronix.de>, Linux kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: question on NUMA page migration * Rik van Riel <riel@...hat.com> wrote: > On 10/19/2012 09:23 PM, Ingo Molnar wrote: > > > >* Rik van Riel <riel@...hat.com> 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists