lkml.org 
[lkml]   [2020]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] makefile: add debug option to enable function aligned on 32 bytes
Hi Andrew,

Thanks for the review.

On Wed, Jul 22, 2020 at 08:39:19PM -0700, Andrew Morton wrote:
> On Thu, 23 Jul 2020 11:30:01 +0800 Feng Tang <feng.tang@intel.com> wrote:
>
> > Recently 0day reported many strange performance changes (regression
> > or improvement), in which there was no obvious relation between
> > the culprit commit and the benchmark at the first look, and it causes
> > people to doubt the test itself is wrong.
> >
> > Upon further check, many of these cases are caused by the change
> > to the alignment of kernel text or data, as whole text/data of kernel
> > are linked together, change in one domain may affect alignments of
> > other domains.
> >
> > gcc has an option '-falign-functions=n' to force text aligned, and with
> > that option enabled, some of those performance changes will be gone,
> > like [1][2][3].
> >
> > Add this option so that developers and 0day can easily find performance
> > bump caused by text alignment change,
>
> Would they use it this way, or would they simply always enable the
> option to reduce the variability

We've had concerns about side effects, like increased kernel size won't be
accepted by embedded system, the possible i-cache usage/contention increase.

And I've only done limited benchmark test, so I thought it may be safer
to be off by default. Though my bold thought was it could be default on :)

> It makes sense, but is it actually known that this does reduce the
> variability?

Yes, at lease for the strange performance bumps reported by 0day, like
in [1][2][3].

> > as tracking these strange bump
> > is quite time consuming. Though it can't help in other cases like data
> > alignment changes like [4].
> >
> > Following is some size data for v5.7 kernel built with a RHEL config
> > used in 0day:
> >
> > text data bss dec filename
> > 19738771 13292906 5554236 38585913 vmlinux.noalign
> > 19758591 13297002 5529660 38585253 vmlinux.align32
> >
> > Raw vmlinux size in bytes:
> >
> > v5.7 v5.7+align32
> > 253950832 254018000 +0.02%
> >
> > Some benchmark data, most of them have no big change:
> >
> > * hackbench: [ -1.8%, +0.5%]
> >
> > * fsmark: [ -3.2%, +3.4%] # ext4/xfs/btrfs
> >
> > * kbuild: [ -2.0%, +0.9%]
> >
> > * will-it-scale: [ -0.5%, +1.8%] # mmap1/pagefault3
> >
> > * netperf:
> > - TCP_CRR [+16.6%, +97.4%]
> > - TCP_RR [-18.5%, -1.8%]
> > - TCP_STREAM [ -1.1%, +1.9%]
>
> What do the numbers in [] mean? The TCP_CRR results look remarkable?

For each of the benchmark listed above, I took 2 or 3 test platforms
and run it with different parameters. So each of the benchmark will
have several cases run, and [] lists the lowest and highest result.

For the netperf/TCP_CRR case, the lowest is +16.6% on a Skylake server
with 16 testing threads, and highest is +97.4 on a Cascadelake server
with 96 testing threads.

Thanks,
Feng

> > [1] https://lore.kernel.org/lkml/20200114085637.GA29297@shao2-debian/
> > [2] https://lore.kernel.org/lkml/20200330011254.GA14393@feng-iot/
> > [3] https://lore.kernel.org/lkml/1d98d1f0-fe84-6df7-f5bd-f4cb2cdb7f45@intel.com/
> > [4] https://lore.kernel.org/lkml/20200205123216.GO12867@shao2-debian/
> >

\
 
 \ /
  Last update: 2020-07-23 07:13    [W:1.218 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site