Re: __{read,write}_once

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Mon, Nov 11, 2019 at 02:39:26PM +0100, Maxime Villard wrote:
> Le 11/11/2019 à 13:51, Joerg Sonnenberger a écrit :
> > On Mon, Nov 11, 2019 at 11:02:47AM +0100, Maxime Villard wrote:
> > > Typically in sys/uvm/uvm_fault.c there are several lockless stat increments
> > > like the following:
> > > 
> > > 	/* Increment the counters.*/
> > > 	uvmexp.fltanget++;
> > 
> > Wasn't the general consensus here to ideally have per-cpu counters here
> > that are aggregated passively?
> 
> In this specific case it's not going to work, because uvmexp is supposed to
> be read from a core dump, and the stats are expected to be found in the
> symbol...

That's just a reason to add code for doing the aggregation, not a reason
to avoid it.

> > I can think of three different options depending the platform:
> > 
> > (1) Use full atomic operations. Fine for true UP platforms and when the
> > overhead of per-CPU precise accounting is too high.
> > 
> > (2) Use uninterruptible memory operations in per CPU memory, aggregate
> > passively on demand.
> > 
> > (3) Emulate uninterruptible memory operations with kernel RAS, aggregate
> > passively on demand.
> 
> Generally I would do (2), but in this specific case I suggest (1).
> atomic_inc_uint is supposed to be implemented on each platform already, so
> it's easy to do.
> 
> (3) is a big headache for a very small reason, and it's not going to
> prevent inter-CPU races.

Problem is that (2) is natively only present on CISC platforms in
general. Most RISC platforms can't do RMW in one instruction. Inter-CPU
races don't matter as long as only the counter of the current CPU is
modified. The main difference between (1) and (2) is the bus lock. (1)
and (3) is primarily a question on whether the atomic operation can be
inlined, if it can't, (3) would still be much nicer.

Joerg