On Thu, Aug 17, 2017 at 1:09 AM, Ingo Molnar <mi...@kernel.org> wrote: > > > * Thomas Garnier <thgar...@google.com> wrote: > > > > > -model=small/medium assume you are on the low 32-bit. It generates > > > > instructions where the virtual addresses have the high 32-bit to be > > > > zero. > > > > > > How are these assumptions hardcoded by GCC? Most of the instructions > > > should be > > > relocatable straight away, as most call/jump/branch instructions are > > > RIP-relative. > > > > I think PIE is capable to use relative instructions well. mcmodel=large > > assumes > > symbols can be anywhere. > > So if the numbers in your changelog and Kconfig text cannot be trusted, > there's > this description of the size impact which I suspect is less susceptible to > measurement error: > > + The kernel and modules will generate slightly more assembly (1 to 2% > + increase on the .text sections). The vmlinux binary will be > + significantly smaller due to less relocations. > > ... but describing a 1-2% kernel text size increase as "slightly more > assembly" > shows a gratituous disregard to kernel code generation quality! In reality > that's > a huge size increase that in most cases will almost directly transfer to a > 1-2% > slowdown for kernel intense workloads. > > > Where does that size increase come from, if PIE is capable of using relative > instructins well? Does it come from the loss of a generic register and the > resulting increase in register pressure, stack spills, etc.?
I will try to gather more information on the size increase. The size increase might be smaller with gcc 4.9 given performance was much better. > > So I'm still unhappy about this all, and about the attitude surrounding it. > > Thanks, > > Ingo -- Thomas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel