From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [PATCHv3 1/2] mm: introduce vm_ops->map_pages() Date: Fri, 28 Feb 2014 22:50:54 +1100 Message-ID: <1393588254.22449.13.camel@pasglop> References: <1393530827-25450-1-git-send-email-kirill.shutemov@linux.intel.com> <1393530827-25450-2-git-send-email-kirill.shutemov@linux.intel.com> <530FB55F.2070106@linux.intel.com> <530FBD8F.7090304@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Linus Torvalds , "Kirill A. Shutemov" , Andrew Morton , Mel Gorman , Rik van Riel , Andi Kleen , Matthew Wilcox , Alexander Viro , Dave Chinner , Ning Qu , linux-mm , linux-fsdevel , Linux Kernel Mailing List , anton@samba.org, Paul Mackerras To: Dave Hansen Return-path: In-Reply-To: <530FBD8F.7090304@linux.intel.com> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2014-02-27 at 14:34 -0800, Dave Hansen wrote: > > The question is really whether or not we ever access the mapping that we > faulted around, though. If we never access it, then the cost (however > small it was) is a loss. That's the mechanism that I'd expect causes > Kirill's numbers to go up after they hit their minimum at ~order-4. On the other hand, the cost of our faults on ppc64 is higher. The two hash lookups by the MMU (generally L2 misses) before it even decides to take the fault, followed by a generally longer code path before we get to Linux fault handler. So there might be a bigger win for us, especially if the "around" pages get pre-hashed (ie, via update_mmu_cache) I don't have the bandwidth to play around with that myself at the moment but I'll try to find somebody who can. Cheers, Ben. -- 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: email@kvack.org