[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190722012750.GB50506@shbuild999.sh.intel.com>
Date: Mon, 22 Jul 2019 09:27:50 +0800
From: Feng Tang <feng.tang@...el.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: "Chen, Rong A" <rong.a.chen@...el.com>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
Shravan Kumar Ramani <sramani@...lanox.com>,
LKP <lkp@...org>, David Woods <dwoods@...lanox.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [LKP] [gpio] f69e00bd21: unixbench.score -24.2% regression
Hi Linus,
On Wed, Jul 17, 2019 at 05:42:15AM +0800, Linus Walleij wrote:
> On Wed, Jul 10, 2019 at 2:15 PM kernel test robot <rong.a.chen@...el.com> wrote:
>
> > FYI, we noticed a -24.2% regression of unixbench.score due to commit:
> > commit: f69e00bd21aa6a1961c521b6eb199137fcb8a76a ("gpio: mmio: Support two direction registers")
> > https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> That's pretty bogus since the test doesn't even seem to be using GPIO.
> Further AFAIK Intel chips don't even use that driver.
>
> Can you provide some rootcausing?
We did some further check, and found this is a false alarm. That some recent
change to LKP itself has enabled the latencytop for newer kernel(post 5.1-rc1),
and latencytop is known to bring extra system load to scheduling related
benchmarks like unixbench, which caused this -24.7 difference of unixbench
score. Sorry for the noise.
Thanks,
Feng
> If you are using GPIOs from userspace in the test somehow I am
> sure both me and Bartosz would be interested to hear how.
>
> Yours,
> Linus Walleij
> _______________________________________________
> LKP mailing list
> LKP@...ts.01.org
> https://lists.01.org/mailman/listinfo/lkp
Powered by blists - more mailing lists