On Tue, Feb 19, 2019 at 08:59:45AM +0800, Wei Yang wrote: > On Mon, Feb 18, 2019 at 03:54:42PM +0800, kernel test robot wrote: > >Greeting, > > > >FYI, we noticed a -12.2% regression of will-it-scale.per_thread_ops due to > >commit: > > > > > >commit: 570d0200123fb4f809aa2f6226e93a458d664d70 ("driver core: move > >device->knode_class to device_private") > >https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master > > > > This is interesting. > > I didn't expect the move of this field will impact the performance. > > The reason is struct device is a hotter memory than device->device_private? > > >in testcase: will-it-scale > >on test machine: 288 threads Knights Mill with 80G memory > >with following parameters: > > > > nr_task: 100% > > mode: thread > > test: unlink2 > > cpufreq_governor: performance > > > >test-description: Will It Scale takes a testcase and runs it from 1 through > >to n parallel copies to see if the testcase will scale. It builds both a > >process and threads based test in order to see any differences between the > >two. > >test-url: https://github.com/antonblanchard/will-it-scale > > > >In addition to that, the commit also has significant impact on the following > >tests: > > > >+------------------+---------------------------------------------------------------+ > >| testcase: change | will-it-scale: will-it-scale.per_thread_ops -29.9% > >regression | > >| test machine | 288 threads Knights Mill with 80G memory > > | > >| test parameters | cpufreq_governor=performance > > | > >| | mode=thread > > | > >| | nr_task=100% > > | > >| | test=signal1 > > |
Ok, I'm going to blame your testing system, or something here, and not the above patch. All this test does is call raise(3). That does not touch the driver core at all. > >+------------------+---------------------------------------------------------------+ > >| testcase: change | will-it-scale: will-it-scale.per_thread_ops -16.5% > >regression | > >| test machine | 288 threads Knights Mill with 80G memory > > | > >| test parameters | cpufreq_governor=performance > > | > >| | mode=thread > > | > >| | nr_task=100% > > | > >| | test=open1 > > | > >+------------------+---------------------------------------------------------------+ Same here, open1 just calls open/close a lot. No driver core interaction at all there either. So are you _sure_ this is the offending patch? thanks, greg k-h