Re: Number of arguments in vmalloc.c

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Dec 06, 2018 at 09:26:24AM -0800, Nadav Amit wrote:
> > On Dec 6, 2018, at 2:25 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > 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).
> 
> Would setting the inline assembly memory operand both as input and output be
> better than using the “volatile”?

I don't know.. I'm forever befuddled by the exact semantics of gcc
inline asm.

> I think that If you do that, the compiler would should the this_cpu_read()
> as something that changes the per-cpu-variable, which would make it invalid
> to re-read the value. At the same time, it would not prevent reordering the
> read with other stuff.

So the thing is; as I wrote, the generic version of this_cpu_*() is:

	local_irq_save();
	__this_cpu_*();
	local_irq_restore();

And per local_irq_{save,restore}() including compiler barriers that
cannot be reordered around either.

And per the principle of least surprise, I think our primitives should
have similar semantics.


I'm actually having difficulty finding the this_cpu_read() in any of the
functions you mention, so I cannot make any concrete suggestions other
than pointing at the alternative functions available.