Messages in this thread | | | Date | Thu, 23 Sep 2021 18:57:44 -0700 | From | Josh Poimboeuf <> | Subject | Re: [RFC PATCH] x86, vmlinux.lds: Add debug option to force all data sections aligned |
| |
On Thu, Sep 23, 2021 at 10:57:20PM +0800, Feng Tang wrote: > For binary size, I just tested 5.14 kernel with a default desktop > config from Ubuntu (I didn't use the normal rhel-8.3 config used > by 0Day, which is more for server): > > v5.14 > ------------------------ > text data bss dec hex filename > 16010221 14971391 6098944 37080556 235cdec vmlinux > > v5.14 + 64B-function-align > -------------------------- > text data bss dec hex filename > 18107373 14971391 6098944 39177708 255cdec vmlinux > > v5.14 + data-align(THREAD_SIZE 16KB) > -------------------------- > text data bss dec hex filename > 16010221 57001791 6008832 79020844 4b5c32c vmlinux
That data size increase is indeed excessive. However I wonder if some other approach (other than SUBALIGN) could be taken. For example, a 4k alignment for each compilation unit's .data section. That might require some linker magic at the built-in.o linking level.
Anyway, I suspect the data alignment issues are less common than function alignment. It might be fine to leave the data alignment as a debug feature for now, as this current patch does.
> > On a similar vein I think we should re-explore permanently enabling > > cacheline-sized function alignment i.e. making something like > > CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B the default. Ingo did some > > research on that a while back: > > > > https://lkml.kernel.org/r/20150519213820.GA31688@gmail.com > > Thanks for sharing this, from which I learned a lot, and I hope I > knew this thread when we first check strange regressions in 2019 :) > > > At the time, the main reported drawback of -falign-functions=64 was that > > even small functions got aligned. But now I think that can be mitigated > > with some new options like -flimit-function-alignment and/or > > -falign-functions=64,X (for some carefully-chosen value of X). > > Will study more about these options. > > If they have much less size increase and no regression in performance, > then maybe it could be turned on by default.
Agreed! I think/hope it would be a net positive change.
I've also been burned by such issues -- like a random one-line code change causing a measurable performance regression due to changed i-cache behavior in unrelated code. It doesn't only affect 0-day tests, it also affects real users.
-- Josh
| |