Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1560208

Re: [RFC PATCH] membarrier: handle nohz_full with expedited thread registration

Show all headers | View raw

----- On Jan 16, 2017, at 6:50 PM, Linus Torvalds torvalds@linux-foundation.org wrote:

> Why not just make the write be a "smp_store_release()", and the read
> be a "smp_load_acquire()". That guarantees a certain amount of
> ordering. The only amount that I suspect makes sense, in fact.
> 
> But it's not clear what the problem is, so..

If we only use a smp_store_release() for the store to membarrier_exped,
the "unregister" (setting back to 0) would be OK, but not the "register",
as the following scenario shows:

Initial values:
A = B = 0

   CPU 0                                  |   CPU 1 (no-hz full)
                                          |
                                          |   membarrier(REGISTER_EXPEDITED)
                                          |     (write barrier implied by store-release)
                                          |     set t->membarrier_exped = 1 (store-release imply memory barrier before store)
                                          |   store B = 1
                                          |   barrier() (compiler-level barrier)
                                          |   store A = 1
   x = load A                             |  
   membarrier(CMD_SHARED)                 |
     smp_mb() [1]                         |
     iter. on nohz cpus                   |
       if iter_t->membarrier_exped == 0   |
          (skip)                          |
     smp_mb() [2]                         |
   y = load B                             |  

Expect: if x == 1, then y == 1

CPU 0 can observe A == 1, membarrier_exped == 0, and B == 0,
because there is no memory barrier between store to
membarrier_exped and store to A on CPU 1.

What we seem to need on the registration/unregistration side
is store-acquire for registration, and store-release for
unregistration. This pairs with a load of membarrier_exped
that has both acquire and release barriers ([1] and [2] above).

> I'm not seeing how a regular fork() could possibly ever make sense to
> have the membarrier state in the newly forked process. Not that
> "fork()" is really well-defined for within a single thread anyway (it
> actually is as far as Linux is concerned, but not in POSIX, afaik).
> 
> So if there is no major reason for it, I would strongly suggest that
> _if_ all this makes sense in the first place, the membarrier thing
> should just be cleared unconditionally both for exec and for
> clone/fork.

That's fine with me!

Thanks,

Mathieu

> 
>               Linus

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC PATCH] membarrier: handle nohz_full with expedited thread registration Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2017-01-16 21:00 +0100
  Re: [RFC PATCH] membarrier: handle nohz_full with expedited thread registration Linus Torvalds <torvalds@linux-foundation.org> - 2017-01-16 21:20 +0100
    Re: [RFC PATCH] membarrier: handle nohz_full with expedited thread  registration Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2017-01-17 00:10 +0100
      Re: [RFC PATCH] membarrier: handle nohz_full with expedited thread registration Linus Torvalds <torvalds@linux-foundation.org> - 2017-01-17 01:00 +0100
        Re: [RFC PATCH] membarrier: handle nohz_full with expedited thread  registration Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2017-01-17 03:10 +0100
      Re: [RFC PATCH] membarrier: handle nohz_full with expedited thread  registration Frederic Weisbecker <fweisbec@gmail.com> - 2017-01-17 05:00 +0100
        Re: [RFC PATCH] membarrier: handle nohz_full with expedited thread  registration Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2017-01-17 23:00 +0100
          Re: [RFC PATCH] membarrier: handle nohz_full with expedited thread  registration Steven Rostedt <rostedt@goodmis.org> - 2017-01-18 00:40 +0100
        Re: [RFC PATCH] membarrier: handle nohz_full with expedited thread  registration "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-01-17 23:10 +0100
          Re: [RFC PATCH] membarrier: handle nohz_full with expedited thread  registration Peter Zijlstra <peterz@infradead.org> - 2017-01-18 12:10 +0100
            Re: [RFC PATCH] membarrier: handle nohz_full with expedited thread registration Paul McKenney <paulmckrcu@gmail.com> - 2017-01-19 23:10 +0100

csiph-web