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


Groups > linux.kernel > #1563133

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

From Paul McKenney <paulmckrcu@gmail.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH] membarrier: handle nohz_full with expedited thread registration
Date 2017-01-19 23:10 +0100
Message-ID <t1t46-7iz-31@gated-at.bofh.it> (permalink)
References (1 earlier) <t0lV0-5Di-17@gated-at.bofh.it> <t0ozv-7pV-15@gated-at.bofh.it> <t0t69-1IC-7@gated-at.bofh.it> <t0K70-4fM-19@gated-at.bofh.it> <t0WhQ-3hP-23@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Jan 18, 2017 at 3:00 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> 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.

Actually, agreed.  After all, if we knew of a solution that made
sense, we would have already implemented it, so some out-of-tree
experimentation makes sense.  One possibility is to have a flag that
user processes could set that aborted (or splatted or whatever) on any
interruption, so that tasks using signal URCU would avoid setting that
flag, and, as you say, tasks setting the flag using URCU would need to
use one of the memory-barrier variants.

                                                       Thanx, Paul

Back to linux.kernel | Previous | NextPrevious 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