Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 11 Oct 2023 12:37:19 -0700 | Subject | Re: [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr() |
| |
On Wed, 11 Oct 2023 at 00:42, Nadav Amit <namit@vmware.com> wrote: > > You are correct. Having said that, for “current" we may be able to do something > better, as regardless to preemption “current" remains the same, and > this_cpu_read_stable() does miss some opportunities to avoid reloading the > value from memory.
It would be lovely to generate even better code, but that this_cpu_read_stable() thing is the best we've come up with. It intentionally has *no* memory inputs or anything else that might make gcc think "I need to re-do this".
For example, instead of using "m" as a memory input, it very intentionally uses "p", to make it clear that that it just uses the _pointer_, not the memory location itself.
That's obviously a lie - it actually does access memory - but it's a lie exactly because of the reason you mention: even when the memory location changes due to preemption (or explicit scheduling), it always changes back to the the value we care about.
So gcc _should_ be able to CSE it in all situations, but it's entirely possible that gcc then decides to re-generate the value for whatever reason. It's a cheap op, so it's ok to regen, of course, but the intent is basically to let the compiler re-use the value as much as possible.
But it *is* probably better to regenerate the value than it would be to spill and re-load it, and from the cases I've seen, this all tends to work fairly well.
Linus
| |