Messages in this thread | | | Date | Wed, 30 Aug 2017 11:01:31 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [RFC PATCH 2/2] membarrier: provide register sync core cmd |
| |
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
| |