From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE77DC433FE for ; Thu, 7 Oct 2021 15:07:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9C9B461175 for ; Thu, 7 Oct 2021 15:07:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242354AbhJGPJX (ORCPT ); Thu, 7 Oct 2021 11:09:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:57858 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242334AbhJGPJW (ORCPT ); Thu, 7 Oct 2021 11:09:22 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 215CE61139; Thu, 7 Oct 2021 15:07:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1633619248; bh=lJ7S4IFViOul+tmNa6zplDV0yMTjTJGHpbM/gcgrLoE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AvUw+d6SB43+nY+6Cz/EHgO5UH477ZuVZWENDMvxH6t7+WDBKMvAWalfTXiQf3uXM 2xa6gtss7/yTtawO9CZnZ5S30NoThoqygVkJTZvrLT9TJvjImT/eAvMs00HvZ095IA nPkh+DZa1lYH/F+QrHlrAo55cOLM77olvWvFO8iA= Date: Thu, 7 Oct 2021 17:07:26 +0200 From: Greg Kroah-Hartman To: Andy Shevchenko Cc: Thorsten Leemhuis , Peter Zijlstra , Thomas Gleixner , Randy Dunlap , Linux Kernel Mailing List , "open list:KERNEL SELFTEST FRAMEWORK" , KUnit Development , Linux Media Mailing List , netdev , Brendan Higgins , "Rafael J. Wysocki" , Ingo Molnar , Will Deacon , Waiman Long , Boqun Feng , Sakari Ailus , Laurent Pinchart , Mauro Carvalho Chehab , Thomas Graf , Herbert Xu , Andrew Morton Subject: Re: [PATCH v2 0/4] kernel.h further split Message-ID: References: <20211007095129.22037-1-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 07, 2021 at 05:47:31PM +0300, Andy Shevchenko wrote: > On Thu, Oct 07, 2021 at 03:59:08PM +0200, Greg Kroah-Hartman wrote: > > On Thu, Oct 07, 2021 at 02:51:15PM +0300, Andy Shevchenko wrote: > > > On Thu, Oct 7, 2021 at 1:34 PM Greg Kroah-Hartman > > > wrote: > > ... > > > > Meanwhile, Thorsten, can you have a look at my approach and tell if it > > > makes sense? > > > > No, do not use ccache when trying to benchmark the speed of kernel > > builds, that tests the speed of your disk subsystem... > > First rule of the measurement is to be sure WHAT we are measuring. > And I'm pretty much explained WHAT and HOW. On the other hand, the > kcbench can't answer to the question about C preprocessing speed > without help of ccache or something similar. > > Measuring complete build is exactly not what we want because of > O(compilation) vs. o(C preprocessing) meaning that any fluctuation > in the former makes silly to measure anything from the latter. > > You see, my theory is proved by practical experiment: > > $ kcbench -i 3 -j 64 -o $O -s $PWD --no-download -m > Processor: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz [88 CPUs] > Cpufreq; Memory: powersave [intel_pstate]; 128823 MiB > Linux running: 5.6.0-2-amd64 [x86_64] > Compiler: gcc (Debian 10.3.0-11) 10.3.0 > Linux compiled: 5.15.0-rc4 > Config; Environment: allmodconfig; CCACHE_DISABLE="1" > Build command: make vmlinux modules > Filling caches: This might take a while... Done > Run 1 (-j 64): 464.07 seconds / 7.76 kernels/hour [P:6001%] > Run 2 (-j 64): 464.64 seconds / 7.75 kernels/hour [P:6000%] > Run 3 (-j 64): 486.41 seconds / 7.40 kernels/hour [P:5727%] > > $ kcbench -i 3 -j 64 -o $O -s $PWD --no-download -m > Processor: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz [88 CPUs] > Cpufreq; Memory: powersave [intel_pstate]; 128823 MiB > Linux running: 5.6.0-2-amd64 [x86_64] > Compiler: gcc (Debian 10.3.0-11) 10.3.0 > Linux compiled: 5.15.0-rc4 > Config; Environment: allmodconfig; CCACHE_DISABLE="1" > Build command: make vmlinux modules > Filling caches: This might take a while... Done > Run 1 (-j 64): 462.32 seconds / 7.79 kernels/hour [P:6009%] > Run 2 (-j 64): 462.33 seconds / 7.79 kernels/hour [P:6006%] > Run 3 (-j 64): 465.45 seconds / 7.73 kernels/hour [P:5999%] > > In [41]: numpy.median(y1) > Out[41]: 464.64 > > In [42]: numpy.median(y2) > Out[42]: 462.33 > > Speedup: +0.5% Good, you measured what actually matters here, the real compilation of the code, not just the pre-processing of it. thanks, greg k-h