[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161117095011.1857bca5@gandalf.local.home>
Date: Thu, 17 Nov 2016 09:50:11 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Lai Jiangshan <jiangshanlai@...il.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Josh Triplett <josh@...htriplett.org>,
stable <stable@...r.kernel.org>
Subject: Re: [PATCH] Fix: disable sys_membarrier when nohz_full is enabled
On Thu, 17 Nov 2016 13:54:27 +0000 (UTC)
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> >> >
> >> > Acked-by: Lai Jiangshan <jiangshanlai@...il.com>
> >> >
> >> > But I'm afraid, in the future, tick_nohz_full will become a default y
> >> > feature. thus it makes sys_membarrier() always disabled. we might
> >> > need a new MEMBARRIER_CMD_XXX to handle it?
> >>
> >> This may require that we send an IPI to nohz_full CPUs, which will
> >> disturb them real-time wise. Any better ideas ?
> >
> > Restrict the IPIs to CPUs running the process executing the
> > sys_membarrier() system call. This would mean that CPUs only
> > are interrupted by their own application's request.
>
> This would break use-cases of cross-process shared memory. :-(
Perhaps make this an opt in. That is, all processes that want to be
affected by this can call this function with some flag that sets a flag
in tasks struct. And have that process get an IPI even in no-hz-full
mode if it asked to do it.
-- Steve
Powered by blists - more mailing lists