TSC "skew" (was: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed])

[Mark Millard]

On 2019-Mar-13, at 12:05, Konstantin Belousov <kostikbel at gmail.com> wrote:

>> . . .
> I am not sure I follow. MFENCE is documented by wording that implies,
> without any doubts, that store buffers are flushed before the
> instruction is retired.  It is not so obvious for SFENCE, which
> sounds like a real fence instead of full flush, at least for normal
> write-back memory where it is NOP as far as ISA is considered.
> 
> It is known and documented in optimization manuals that locked
> operations are much more efficient, but locked ops are only documented
> to ensure ordering and not flush.  So SFENCE is not suitable as our
> barrier.

What I've seen in papers for the C++ Load/Store Seq Cst mappings to 
processors is:

For write-fencing style:

Load Seq Cst:                MOV from memory
Store Seq Cst alternative 0: XCHG (which as an implicit lock prefix)
Store Seq Cst alternative 1: MOV into memory; MFENCE

For read-fencing style:

Load Seq Cst alternative 0: LOCK XADD(0)
Load Seq Cst alternative 1: MFENCE; MOV from memory
Store Seq Cst:              MOV into memory

There is also:

Seq Cst Fence: MFENCE

I've never seen SFENCE (or LFENCE) suggested for any of the above.

I would expect for C++ Seq Cst that the XCHG and the LOCK XADD(0)
would need to flush store buffers in order for those alternatives
to be valid for C++ Seq Cst.

I've seen a reference to a "locked identity operation to the top of
stack" as another form of locked style of Seq Cst fencing.

(write-fencing and read-fencing can not be generally mixed for Seq
Cst: they do not inter-operate.)

> And, the second point, LFENCE there does not work as barrier for IPC.
> It only ensures that RDTSC is not started earlier than the previous
> instructions.  No store buffer flushing is done.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)