Re: [PATCH] x86: Pack loops tightly as well

Borislav Petkov
2015-04-10T13:48:28Z

On Fri, Apr 10, 2015 at 02:30:18PM +0200, Ingo Molnar wrote:
> And the final patch below also packs loops tightly:
>
> text data bss dec filename
> 12566391 1617840 1089536 15273767 vmlinux.align.16-byte
> 12224951 1617840 1089536 14932327 vmlinux.align.1-byte
> 11976567 1617840 1089536 14683943 vmlinux.align.1-byte.funcs-1-byte
> 11903735 1617840 1089536 14611111 vmlinux.align.1-byte.funcs-1-byte.loops-1-byte
>
> The total reduction is 5.5%.
>
> Now loop alignment is beneficial if:
>
> - a loop is cache-hot and its surroundings are not.
>
> Loop alignment is harmful if:
>
> - a loop is cache-cold
> - a loop's surroundings are cache-hot as well
> - two cache-hot loops are close to each other
>
> and I'd argue that the latter three harmful scenarios are much more
> common in the kernel. Similar arguments can be made for function
> alignment as well. (Jump target alignment is a bit different but I
> think the same conclusion holds.)

So I IMHO think the loop alignment is coupled to the fetch window size
and alignment. I'm looking at the AMD opt. manuals and both for fam 0x15
and 0x16 say that hot loops should be 32-byte aligned due to 32-byte
aligned fetch window in each cycle.

So if we have hot loops, we probably want them 32-byte aligned (I don't
know what that number on Intel is, need to look).

Family 0x16 says, in addition, that if you have branches in those loops,
the first two branches in a cacheline can be processed in a cycle when
they're in the branch predictor. And so to guarantee that you should
align your loop start to a cacheline.

And this all depends on the uarch so I can imagine optimizing for the
one would harm the other.

Looks like a long project of experimenting and running perf counters :-)

--
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--