Re: [RFC PATCH 2/2] membarrier: provide register sync core cmd

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Wed, Aug 30, 2017 at 05:53:53PM +0000, Mathieu Desnoyers wrote:
> ----- On Aug 28, 2017, at 1:49 PM, Paul E. McKenney paulmck@linux.vnet.ibm.com wrote:
> 
> > On Sun, Aug 27, 2017 at 09:39:54PM +0000, Mathieu Desnoyers wrote:
> >> ----- On Aug 27, 2017, at 2:00 PM, Paul E. McKenney paulmck@linux.vnet.ibm.com
> >> wrote:
> >> 
> >> > On Sun, Aug 27, 2017 at 08:52:58PM +0000, Mathieu Desnoyers wrote:
> >> >> ----- On Aug 27, 2017, at 1:35 PM, Paul E. McKenney paulmck@linux.vnet.ibm.com
> >> >> wrote:
> >> >> 
> >> >> > On Sun, Aug 27, 2017 at 12:54:04PM -0700, Mathieu Desnoyers wrote:
> >> >> >> Add a new MEMBARRIER_CMD_REGISTER_SYNC_CORE command to the membarrier
> >> >> >> system call. It allows processes to register their intent to have their
> >> >> >> threads issue core serializing barriers in addition to memory barriers
> >> >> >> whenever a membarrier command is performed.
> >> >> >> 
> >> >> >> It is relevant for reclaim of JIT code, which requires to issue core
> >> >> >> serializing barriers on all threads running on behalf of a process
> >> >> >> after ensuring the old code is not visible anymore, before re-using
> >> >> >> memory for new code.
> >> >> >> 
> >> >> >> When a processes returns from a MEMBARRIER_CMD_REGISTER_SYNC_CORE
> >> >> >> command, it is guaranteed that all following MEMBARRIER_CMD_SHARED and
> >> >> >> MEMBARRIER_CMD_PRIVATE_EXPEDITED issue core serializing barriers, in
> >> >> >> addition to the memory barriers, on all of its running threads.
> >> >> > 
> >> >> > I have queued both of these for testing and review:
> >> >> > 
> >> >> >  git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> >> >> >  f54cf5123eb9 ("membarrier: Speed up single-threaded private cmd")
> >> >> >  0d6eb99818da ("membarrier: Provide register sync core cmd")
> >> >> > 
> >> >> > Could the people who asked for this please test it?  The second commit
> >> >> > is non-obvious enough to need some careful review and intensive testing
> >> >> > before I can in good conscious pass it upstream.
> >> >> 
> >> >> Thanks Paul!
> >> >> 
> >> >> Can you pick up my v2 instead ? I added benchmarks in the changelog and
> >> >> documented the new command in the membarrier public header. No changes
> >> >> otherwise.
> >> > 
> >> > It looks like 0day Test Robot also wants some additional header files.
> >> > Could you please send me a v3 with its complaints addressed?
> >> 
> >> I sent a separate patch implementing sync_core() on xtensa. It should
> >> be applied before this patch.
> > 
> > And it looks like we also need a sync_core() on every CPU family other
> > than x86, which already has one.  Do we want to make this capability
> > depend on an ARCH_ kconfig option, or should we just bit the bullet and
> > implement sync_core() everywhere?
> > 
> > (I had to drop this commit due to downstream complaints.  Left to myself,
> > I would take the ARCH_ approach, then add it back in, but please let me
> > know how you would like to proceed.)
> 
> I plan to go with the ARCH_ approach indeed.

Sounds good, looking forward to seeing it.  ;-)

							Thanx, Paul