[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG48ez0N9rTEtrA1TrL07r5Om_yK-10XO2XtsWOn3Nde0PXsZA@mail.gmail.com>
Date: Fri, 21 Feb 2020 16:55:42 +0100
From: Jann Horn <jannh@...gle.com>
To: kernel test robot <rong.a.chen@...el.com>
Cc: Will Deacon <will@...nel.org>,
Maddie Stone <maddiestone@...gle.com>,
Kees Cook <keescook@...omium.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
Will Deacon <will.deacon@....com>, lkp@...ts.01.org
Subject: Re: [kernel] 247f5d7caa: will-it-scale.per_process_ops 9.6% improvement
On Fri, Feb 21, 2020 at 12:56 PM kernel test robot
<rong.a.chen@...el.com> wrote:
> FYI, we noticed a 9.6% improvement of will-it-scale.per_process_ops due to commit:
>
>
> commit: 247f5d7caa443d0ea5f1992aeda875e679e9bd35 ("kernel-hacking: Make DEBUG_{LIST,PLIST,SG,NOTIFIERS} non-debug options")
> https://git.kernel.org/cgit/linux/kernel/git/will/linux.git debug-list
I'm guessing this might mean that the test bot had the DEBUG_LIST
stuff enabled in its Kconfig, whereas after the rename, the default is
used, which is off?
This seems a bit problematic if people had DEBUG_LIST enabled in their
old kernel config and then try to reuse that config for a new kernel.
I wonder whether it'd be acceptable to keep the options under their
old names and let them "select" the new ones, or whether we have to
choose between "keep the old bad name" and "discard people's old
config flags".
Powered by blists - more mailing lists