[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1393588254.22449.13.camel@pasglop>
Date: Fri, 28 Feb 2014 22:50:54 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mgorman@...e.de>, Rik van Riel <riel@...hat.com>,
Andi Kleen <ak@...ux.intel.com>,
Matthew Wilcox <matthew.r.wilcox@...el.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Dave Chinner <david@...morbit.com>, Ning Qu <quning@...il.com>,
linux-mm <linux-mm@...ck.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
anton@...ba.org, Paul Mackerras <paulus@...ba.org>
Subject: Re: [PATCHv3 1/2] mm: introduce vm_ops->map_pages()
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 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