Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752190AbaB0V21 (ORCPT ); Thu, 27 Feb 2014 16:28:27 -0500 Received: from mail-vc0-f173.google.com ([209.85.220.173]:60564 "EHLO mail-vc0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751067AbaB0V2Y (ORCPT ); Thu, 27 Feb 2014 16:28:24 -0500 MIME-Version: 1.0 In-Reply-To: <1393530827-25450-1-git-send-email-kirill.shutemov@linux.intel.com> References: <1393530827-25450-1-git-send-email-kirill.shutemov@linux.intel.com> Date: Thu, 27 Feb 2014 13:28:22 -0800 X-Google-Sender-Auth: Xr3wdp5fubZA5ROVVYJcGW7IIfs Message-ID: Subject: Re: [PATCHv3 0/2] mm: map few pages around fault address if they are in page cache From: Linus Torvalds To: "Kirill A. Shutemov" Cc: Andrew Morton , Mel Gorman , Rik van Riel , Andi Kleen , Matthew Wilcox , Dave Hansen , Alexander Viro , Dave Chinner , Ning Qu , linux-mm , linux-fsdevel , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 27, 2014 at 11:53 AM, Kirill A. Shutemov wrote: > Here's new version of faultaround patchset. It took a while to tune it and > collect performance data. Andrew, mind taking this into -mm with my acks? It's based on top of Kirill's cleanup patches that I think are also in your tree. Kirill - no complaints from me. I do have two minor issues that you might satisfy, but I think the patch is fine as-is. The issues/questions are: (a) could you test this on a couple of different architectures? Even if you just have access to intel machines, testing it across a couple of generations of microarchitectures would be good. The reason I say that is that from my profiles, it *looks* like the page fault costs are relatively higher on Ivybridge/Haswell than on some earlier uarchs. Now, I may well be wrong about the uarch issue, and maybe I just didn't notice it as much before. I've stared at a lot of profiles over the years, though, and the page fault cost seems to stand out much more than it used to. And don't get me wrong - it might not be because Ivy/Haswell is any worse, it might just be that exception performance hasn't improved together with some other improvements. (b) I suspect we should try to strongly discourage filesystems from actually using map_pages unless they use the standard filemap_map_pages function as-is. Even with the fairly clean interface, and forcing people to use "do_set_pte()", I think the docs might want to try to more explicitly discourage people from using this to do their own hacks.. Hmm? Either way, even without those questions answered, I'm happy with how your patches look. Linus -- 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/