From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754249AbdARLDM (ORCPT <rfc822;w@1wt.eu>);
        Wed, 18 Jan 2017 06:03:12 -0500
Received: from merlin.infradead.org ([205.233.59.134]:51084 "EHLO
        merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753076AbdARLDJ (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 18 Jan 2017 06:03:09 -0500
Date: Wed, 18 Jan 2017 12:00:58 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Josh Triplett <josh@joshtriplett.org>,
        KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
        rostedt <rostedt@goodmis.org>, Nicholas Miell <nmiell@comcast.net>,
        Ingo Molnar <mingo@redhat.com>,
        One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
        Lai Jiangshan <laijs@cn.fujitsu.com>,
        Stephen Hemminger <stephen@networkplumber.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        David Howells <dhowells@redhat.com>,
        bobby prani <bobby.prani@gmail.com>,
        Michael Kerrisk <mtk.manpages@gmail.com>,
        Shuah Khan <shuahkh@osg.samsung.com>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH] membarrier: handle nohz_full with expedited thread
 registration
Message-ID: <20170118110058.GE6485@twins.programming.kicks-ass.net>
References: <1484596275-30412-1-git-send-email-mathieu.desnoyers@efficios.com>
 <CA+55aFz01xaATut1r_FmzB7v39JngjjydqmKHivy+-5a1bbSKg@mail.gmail.com>
 <1587103499.5523.1484607367124.JavaMail.zimbra@efficios.com>
 <20170117035521.GB2787@lerouge>
 <20170117205321.GF5238@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170117205321.GF5238@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.23.1 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.