From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755886Ab2IMXFM (ORCPT ); Thu, 13 Sep 2012 19:05:12 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:51264 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750940Ab2IMXFJ (ORCPT ); Thu, 13 Sep 2012 19:05:09 -0400 Date: Thu, 13 Sep 2012 16:05:06 -0700 From: Andrew Morton To: "Kirill A. Shutemov" Cc: linux-mm@kvack.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Andi Kleen , Tim Chen , Alex Shi , Jan Beulich , Robert Richter , Andy Lutomirski , Andrea Arcangeli , Johannes Weiner , Hugh Dickins , KAMEZAWA Hiroyuki , Mel Gorman , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mips@linux-mips.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org Subject: Re: [PATCH v4 0/8] Avoid cache trashing on clearing huge/gigantic page Message-Id: <20120913160506.d394392a.akpm@linux-foundation.org> In-Reply-To: <1345470757-12005-1-git-send-email-kirill.shutemov@linux.intel.com> References: <1345470757-12005-1-git-send-email-kirill.shutemov@linux.intel.com> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 20 Aug 2012 16:52:29 +0300 "Kirill A. Shutemov" wrote: > Clearing a 2MB huge page will typically blow away several levels of CPU > caches. To avoid this only cache clear the 4K area around the fault > address and use a cache avoiding clears for the rest of the 2MB area. > > This patchset implements cache avoiding version of clear_page only for > x86. If an architecture wants to provide cache avoiding version of > clear_page it should to define ARCH_HAS_USER_NOCACHE to 1 and implement > clear_page_nocache() and clear_user_highpage_nocache(). Patchset looks nice to me, but the changelogs are terribly short of performance measurements. For this sort of change I do think it is important that pretty exhaustive testing be performed, and that the results (or a readable summary of them) be shown. And that testing should be designed to probe for slowdowns, not just the speedups!