Re: [RFC PATCH 00/19] Foundation for automatic NUMA balancing
[Posted November 14, 2012 by corbet]
| From: |
| Andrea Arcangeli <aarcange-AT-redhat.com> |
| To: |
| Mel Gorman <mgorman-AT-suse.de> |
| Subject: |
| Re: [RFC PATCH 00/19] Foundation for automatic NUMA balancing |
| Date: |
| Fri, 9 Nov 2012 15:42:57 +0100 |
| Message-ID: |
| <20121109144257.GA26870@redhat.com> |
| Cc: |
| Peter Zijlstra <a.p.zijlstra-AT-chello.nl>, Ingo Molnar <mingo-AT-kernel.org>,
Rik van Riel <riel-AT-redhat.com>, Johannes Weiner <hannes-AT-cmpxchg.org>,
Hugh Dickins <hughd-AT-google.com>, Thomas Gleixner <tglx-AT-linutronix.de>,
Linus Torvalds <torvalds-AT-linux-foundation.org>,
Andrew Morton <akpm-AT-linux-foundation.org>,
Linux-MM <linux-mm-AT-kvack.org>, LKML <linux-kernel-AT-vger.kernel.org> |
| Archive-link: |
| Article, Thread
|
Hi Mel,
On Tue, Nov 06, 2012 at 09:14:36AM +0000, Mel Gorman wrote:
> This series addresses part of the integration and sharing problem by
> implementing a foundation that either the policy for schednuma or autonuma
> can be rebased on. The actual policy it implements is a very stupid
> greedy policy called "Migrate On Reference Of pte_numa Node (MORON)".
> While stupid, it can be faster than the vanilla kernel and the expectation
> is that any clever policy should be able to beat MORON. The advantage is
> that it still defines how the policy needs to hook into the core code --
> scheduler and mempolicy mostly so many optimisations (s uch as native THP
> migration) can be shared between different policy implementations.
I haven't had much time to look into it yet, because I've been
attending KVM Forum the last few days, but this foundation looks ok
with me as a starting base and I ack it for merging it upstream. I'll
try to rebase on top of this and send you some patches.
> Patch 14 adds a MPOL_MF_LAZY mempolicy that an interested application can use.
> On the next reference the memory should be migrated to the node that
> references the memory.
This approach of starting with a stripped down foundation won't allow
for easy backportability anyway, so merging the userland API at the
first step shouldn't provide any benefit for the work that is ahead of
us. I would leave this for later and not part of the foundation.
All we need is a failsafe runtime and boot time turn off knob, just in
case.
Thanks,
Andrea
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
(
Log in to post comments)