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

Groups > linux.kernel > #1560173

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

Show all headers | View raw

On Mon, Jan 16, 2017 at 2:56 PM, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> So for both register and unregister functions, as well as the use in
> membarrier_nohz_full_expedited(), disabling interrupts around the rq
> lock should fix this. But perhaps it would be wiser trying not to use the
> rq lock at all.

Definitely.


>> (d) when it doesn't even make any sense in the first place for a
>> per-thread value that is never modified by any other threads!
>
> The variable "membarrier_expedited" is indeed only modified by the
> current thread, but it is read by other threads calling
> membarrier_nohz_full_expedited().

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..

>> Oh, and the clone semantics make no sense either.
>
> Currently, this patch clears the state on exec and when forking a new thread,
> but keeps the thread state when forking a new process, which AFAIU is
> in line with current practices. But perhaps not, what I am missing ?

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.

              Linus

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