From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932667AbcAHSb5 (ORCPT ); Fri, 8 Jan 2016 13:31:57 -0500 Received: from terminus.zytor.com ([198.137.202.10]:57827 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932507AbcAHSbz (ORCPT ); Fri, 8 Jan 2016 13:31:55 -0500 Date: Fri, 8 Jan 2016 10:30:53 -0800 From: tip-bot for Chris Wilson Message-ID: Cc: tglx@linutronix.de, ross.zwisler@linux.intel.com, mcgrof@suse.com, chris@chris-wilson.co.uk, bp@suse.de, hpa@zytor.com, linux-kernel@vger.kernel.org, mingo@kernel.org, sfr@canb.auug.org.au, sai.praneeth.prakhya@intel.com, toshi.kani@hpe.com Reply-To: toshi.kani@hpe.com, sai.praneeth.prakhya@intel.com, sfr@canb.auug.org.au, mingo@kernel.org, linux-kernel@vger.kernel.org, hpa@zytor.com, bp@suse.de, mcgrof@suse.com, chris@chris-wilson.co.uk, ross.zwisler@linux.intel.com, tglx@linutronix.de In-Reply-To: <1452246933-10890-1-git-send-email-chris@chris-wilson.co.uk> References: <1452246933-10890-1-git-send-email-chris@chris-wilson.co.uk> To: linux-tip-commits@vger.kernel.org Subject: [tip:x86/mm] x86/mm: Micro-optimise clflush_cache_range() Git-Commit-ID: 1f1a89ac05f6e88aa341e86e57435fdbb1177c0c X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 1f1a89ac05f6e88aa341e86e57435fdbb1177c0c Gitweb: http://git.kernel.org/tip/1f1a89ac05f6e88aa341e86e57435fdbb1177c0c Author: Chris Wilson AuthorDate: Fri, 8 Jan 2016 09:55:33 +0000 Committer: Thomas Gleixner CommitDate: Fri, 8 Jan 2016 19:27:39 +0100 x86/mm: Micro-optimise clflush_cache_range() Whilst inspecting the asm for clflush_cache_range() and some perf profiles that required extensive flushing of single cachelines (from part of the intel-gpu-tools GPU benchmarks), we noticed that gcc was reloading boot_cpu_data.x86_clflush_size on every iteration of the loop. We can manually hoist that read which perf regarded as taking ~25% of the function time for a single cacheline flush. Signed-off-by: Chris Wilson Reviewed-by: Ross Zwisler Acked-by: "H. Peter Anvin" Cc: Toshi Kani Cc: Borislav Petkov Cc: Luis R. Rodriguez Cc: Stephen Rothwell Cc: Sai Praneeth Link: http://lkml.kernel.org/r/1452246933-10890-1-git-send-email-chris@chris-wilson.co.uk Signed-off-by: Thomas Gleixner --- arch/x86/mm/pageattr.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c index a3137a4..6000ad7 100644 --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -129,14 +129,16 @@ within(unsigned long addr, unsigned long start, unsigned long end) */ void clflush_cache_range(void *vaddr, unsigned int size) { - unsigned long clflush_mask = boot_cpu_data.x86_clflush_size - 1; + const unsigned long clflush_size = boot_cpu_data.x86_clflush_size; + void *p = (void *)((unsigned long)vaddr & ~(clflush_size - 1)); void *vend = vaddr + size; - void *p; + + if (p >= vend) + return; mb(); - for (p = (void *)((unsigned long)vaddr & ~clflush_mask); - p < vend; p += boot_cpu_data.x86_clflush_size) + for (; p < vend; p += clflush_size) clflushopt(p); mb();