Messages in this thread | | | From | Sebastian Andrzej Siewior <> | Subject | [PATCH 0/3] Remove volatile from arch_raw_cpu_ptr() and revert the hacks. | Date | Thu, 24 Mar 2022 18:39:24 +0100 |
| |
On 2022-03-23 10:17:08 [-0700], Linus Torvalds wrote: > I get the feeling that the real problem is that on x86, we have this: > > #define arch_raw_cpu_ptr(ptr) \ > ({ \ > unsigned long tcp_ptr__; \ > asm volatile("add " __percpu_arg(1) ", %0" \ > : "=r" (tcp_ptr__) \ > : "m" (this_cpu_off), "0" (ptr)); \ > (typeof(*(ptr)) __kernel __force *)tcp_ptr__; \ > }) > > and that "volatile" is just *WRONG*. > > That volatile is what literally tells the compiler "you can't remove > this if it isn't used".
It is indeed just x86. After double checking arm/mips removes that code properly.
> But there's no point to that. > > So how about we > > (a) just revert commit 9983a9d577db4 > > (b) remove that bogus 'volatile' > > Doesn't that fix the problem?
The following series does that. The assembly code looks okay. In a few simple test cases the this_cpu_ptr() usage is always created and is not moved passed preempt_enable() statement. The resulting vmlinux shrunk a bit. The test config lost ~2KiB: text data bss dec hex filename 22533901 10722831 13963496 47220228 2d08604 vmlinux.volatile 22531589 10722831 13971688 47226108 2d09cfc vmlinux.patched
after looking at it it was sometimes due avoiding this_cpu_ptr(), sometimes it looked that the compiler made other decisions at the earlier resulting to be more beneficial later on.
Sebastian
| |