Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934703AbdC3S4h (ORCPT ); Thu, 30 Mar 2017 14:56:37 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:33707 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933891AbdC3S4f (ORCPT ); Thu, 30 Mar 2017 14:56:35 -0400 MIME-Version: 1.0 In-Reply-To: <20170330184824.GS29622@ZenIV.linux.org.uk> References: <20170329055706.GH29622@ZenIV.linux.org.uk> <20170330162241.GG7909@n2100.armlinux.org.uk> <20170330164342.GR29622@ZenIV.linux.org.uk> <20170330184824.GS29622@ZenIV.linux.org.uk> From: Linus Torvalds Date: Thu, 30 Mar 2017 11:56:33 -0700 X-Google-Sender-Auth: BO_uCW9n3g0eNmbKmk7EgX_Hxjc Message-ID: Subject: Re: [RFC][CFT][PATCHSET v1] uaccess unification To: Al Viro Cc: Russell King - ARM Linux , "linux-arch@vger.kernel.org" , Linux Kernel Mailing List , Richard Henderson , Will Deacon , Haavard Skinnemoen , Vineet Gupta , Steven Miao , Jesper Nilsson , Mark Salter , Yoshinori Sato , Richard Kuo , Tony Luck , Geert Uytterhoeven , James Hogan , Michal Simek , David Howells , Ley Foon Tan , Jonas Bonn , Helge Deller , Martin Schwidefsky , Ralf Baechle , Benjamin Herrenschmidt , Chen Liqin , "David S. Miller" , Chris Metcalf , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Chris Zankel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1352 Lines: 34 On Thu, Mar 30, 2017 at 11:48 AM, Al Viro wrote: > > This is not going into the tree - it's just a "let's check your > theory about might_fault() overhead being the source of slowdown > you are seeing" quick-and-dirty patch. Note that for cached hdparm reads, I suspect a *much* bigger effects than the fairly cheap might_fault() tests is just the random layout of the data in the page cache. Memory is just more expensive than CPU is. The precise physical address that gets allocated for the page cache entries ends up mattering, and is obviously fairly "sticky" within one reboot (unless you have a huge working set and that flushes it, or you use something like echo 3 > /proc/sys/vm/drop_caches to flush filesystem caches manually). The reason things like page allocation matter for performance testing is simply that the CPU caches are physically indexed (the L1 might not be, but outer levels definitely are), and so page allocation ends up impacting caching unless you have very high associativity. And even if your workload doesn't fit in your CPU caches (I'd hope that the "cached" hdparm is still doing a fairly big area), you'll still see memory performance depend on physical addresses. Doing kernel performance testing without rebooting several times is generally very hard. Linus