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

Groups > linux.kernel > #1561546

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

Show all headers | View raw

On Tue, Jan 17, 2017 at 12:53:21PM -0800, Paul E. McKenney wrote:
> On Tue, Jan 17, 2017 at 04:55:22AM +0100, Frederic Weisbecker wrote:
> 
> [ . . . ]
> 
> > In fact due to the complexity involved, I have to ask first if we
> > really need this feature.  Typically nohz_full workloads don't want to
> > be disturbed at all, so do we have real and significant usecases of CPU
> > isolation workloads that want to be concerned by this membarrier so much
> > that they can tolerate some random IRQ?
> 
> I believe that we need to explore the options for implementing it and
> to -at- -least- have a patch ready, even if that patch doesn't go
> upstream immediately.

I tend to agree with Frederic here in that the design requirements seem
mutually exclusive.

NOHZ_FULL users do _not_ want interruptions of any sort, in fact some
want to make that a hard fail of the task.

OTOH sys_membarrier(CMD_SHARED) promises to serialize against anything
observable.

The only logical solution is to error the sys_membarrier(CMD_SHARED)
call when a NOHZ_FULL task shares memory with the caller. Now
determining this is somewhat tricky of course :/


I really don't see how there is another possible solution that makes
sense here. If there is shared memory between a NOHZ_FULL task and
others, a urcu implementation used by those must not rely on
sys_membarrier() but instead use a more expensive one, for instance one
where rcu_read_{,un}lock() do explicit counting and have memory barriers
in.

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