Messages in this thread | | | From | Uros Bizjak <> | Date | Fri, 20 Oct 2023 09:57:46 +0200 | Subject | Re: [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr() |
| |
On Thu, Oct 19, 2023 at 9:07 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Thu, 19 Oct 2023 at 11:49, Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > Honestly, I've actually never seen gcc rematerialize anything at all. > > > > I really only started worrying about remat issues in a theoretical > > sense, and because I feel it would be relatively *easy* to do for > > something where the source is a load. > > .. I started looking around, since I actually have gcc sources around. > > At least lra-remat.cc explicitly says > > o no any memory (as access to memory is non-profitable) > > so if we could just *rely* on that, it would actually allow us to use > memory ops without the volatile. > > That would be the best of all worlds, of course.
I have made an experiment and changed:
#define __raw_cpu_read(qual, pcp) \ ({ \ - *(qual __my_cpu_type(pcp) *)__my_cpu_ptr(&(pcp)); \ + *(__my_cpu_type(pcp) *)__my_cpu_ptr(&(pcp)); \ })
#define __raw_cpu_write(qual, pcp, val) \ do { \ - *(qual __my_cpu_type(pcp) *)__my_cpu_ptr(&(pcp)) = (val); \ + *(__my_cpu_type(pcp) *)__my_cpu_ptr(&(pcp)) = (val); \ } while (0)
Basically, I removed "volatile" from read/write accessors. With all new percpu patches in place the difference in all percpu accesses is:
Reference: 15990 accesses Patched: 15976 accesses.
So, the difference is 14 fewer accesses. Waaay too low of a gain for a potential pain.
The code size savings are:
text data bss dec hex filename 25476129 4389468 808452 30674049 1d40c81 vmlinux-new.o 25476021 4389444 808452 30673917 1d40bfd vmlinux-ref.o
So, 108 bytes for the default build.
Uros.
| |