Re: [RFC PATCH] makefile: add debug option to enable function aligned on 32 bytes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 23 Jul 2020 11:30:01 +0800 Feng Tang <feng.tang@xxxxxxxxx> 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?

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

> 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?

> [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@xxxxxxxxx/
> [4] https://lore.kernel.org/lkml/20200205123216.GO12867@shao2-debian/
> 




[Index of Archives]     [Linux&nblp;USB Development]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite Secrets]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux