From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Lankes Subject: RE: [RFC PATCH 0/4]: affinity-on-next-touch Date: Fri, 12 Jun 2009 15:21:15 +0200 Message-ID: <004501c9eb60$a9abb4c0$fd031e40$@rwth-aachen.de> References: <000c01c9d212$4c244720$e46cd560$@rwth-aachen.de> <87zldjn597.fsf@basil.nowhere.org> <000001c9eac4$cb8b6690$62a233b0$@rwth-aachen.de> <20090612103251.GJ25568@one.firstfloor.org> <004001c9eb53$71991300$54cb3900$@rwth-aachen.de> <4A324A4E.1060405@inria.fr> Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Return-path: In-reply-to: <4A324A4E.1060405@inria.fr> Content-language: de Sender: linux-numa-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: 'Brice Goglin' Cc: 'Andi Kleen' , linux-kernel@vger.kernel.org, Lee.Schermerhorn@hp.com, linux-numa@vger.kernel.org, Boris Bierbaum > So mbind(MPOL_MF_LAZY) is taking care of changing page protection so as > to generate page-faults on next-touch? (instead of your madvise) > Is it migrating the whole memory area? Or only single pages? mbind removes the pte references. Page migration will occur, when a task access to one of these unmapped pages. Therefore, Lee's solution migrate one single page and not the whole area. You find further information at slides 19-23 of http://mirror.linux.org.au/pub/linux.conf.au/2007/video/talks/197.pdf. > Then, what's happening with MPOL_MF_LAZY in the kernel? Is it actually > stored in the mempolicy? If so, couldn't another fault later cause > another migration? > Or is MPOL_MF_LAZY filtered out of the policy once the protection of > all > PTE has been changed? > > I don't see why we need a new mempolicy here. If we are migrating > single > pages, migrate-on-next-touch looks like a page-attribute to me. There > should be nothing to store in a mempolicy/VMA/whatever. > MPOL_MF_LAZY is used as flag and does not specify a new policy. Therefore, MPOL_MF_LAZY isn't stored in a VMA. The flag is only used to detect that the system call mbind has to unmap these pages. Stefan