Re: Number of arguments in vmalloc.c

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Dec 06, 2018 at 12:28:26AM -0800, Nadav Amit wrote:
> [ +Peter ]
> 
> So I dug some more (I’m still not done), and found various trivial things
> (e.g., storing zero extending u32 immediate is shorter for registers,
> inlining already takes place).
> 
> *But* there is one thing that may require some attention - patch
> b59167ac7bafd ("x86/percpu: Fix this_cpu_read()”) set ordering constraints
> on the VM_ARGS() evaluation. And this patch also imposes, it appears,
> (unnecessary) constraints on other pieces of code.
> 
> These constraints are due to the addition of the volatile keyword for
> this_cpu_read() by the patch. This affects at least 68 functions in my
> kernel build, some of which are hot (I think), e.g., finish_task_switch(),
> smp_x86_platform_ipi() and select_idle_sibling().
> 
> Peter, perhaps the solution was too big of a hammer? Is it possible instead
> to create a separate "this_cpu_read_once()” with the volatile keyword? Such
> a function can be used for native_sched_clock() and other seqlocks, etc.

No. like the commit writes this_cpu_read() _must_ imply READ_ONCE(). If
you want something else, use something else, there's plenty other
options available.

There's this_cpu_op_stable(), but also __this_cpu_read() and
raw_this_cpu_read() (which currently don't differ from this_cpu_read()
but could).