From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753680AbcKIMm3 (ORCPT ); Wed, 9 Nov 2016 07:42:29 -0500 Received: from mail.skyhub.de ([78.46.96.112]:51439 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932434AbcKIMmR (ORCPT ); Wed, 9 Nov 2016 07:42:17 -0500 Date: Wed, 9 Nov 2016 13:42:14 +0100 From: Borislav Petkov To: kernel test robot Cc: Ingo Molnar , Andy Lutomirski , Brian Gerst , Denys Vlasenko , "H. Peter Anvin" , Josh Poimboeuf , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , LKML , tipbuild@zytor.com, lkp@01.org, Mel Gorman Subject: Re: [lkp] [x86/copy_user] adb402cd14: will-it-scale.per_process_ops -12.7% regression Message-ID: <20161109124214.sjasqcurv6gi64ol@pd.tnic> References: <20161107025038.GE21529@yexl-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20161107025038.GE21529@yexl-desktop> User-Agent: NeoMutt/20161014 (1.7.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 07, 2016 at 10:50:38AM +0800, kernel test robot wrote: > > Greeting, > > FYI, we noticed a -12.7% regression of will-it-scale.per_process_ops due to commit: > > > commit adb402cd1461eef6e1a21db4532a3b9e6a6be853 ("x86/copy_user: Unify the code by removing the 64-bit asm _copy_*_user() variants") > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/asm > > in testcase: will-it-scale > on test machine: 8 threads Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz with 4G memory > with following parameters: > > test: poll1 > cpufreq_governor: performance ... > # Lock Debugging (spinlocks, mutexes, etc...) > # > # CONFIG_DEBUG_RT_MUTEXES is not set > # CONFIG_DEBUG_SPINLOCK is not set > # CONFIG_DEBUG_MUTEXES is not set > # CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set > # CONFIG_DEBUG_LOCK_ALLOC is not set > # CONFIG_PROVE_LOCKING is not set > # CONFIG_LOCK_STAT is not set > CONFIG_DEBUG_ATOMIC_SLEEP=y ^^^^^^^^^^^^^^^^^^^^^^^^^ So Mel says that this might be the culprit for the observed change in perf. Can you please rerun your test without that CONFIG_DEBUG_ATOMIC_SLEEP thing? Thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.