RE: [PATCH RFC 01/16] prcu: Add PRCU implementation

[zhangheng (AC)]

-----Original Message-----
>From: Boqun Feng [mailto:boqun.feng@xxxxxxxxx] 
>Sent: 2018年1月30日 14:41
>To: zhangheng (AC) <heng.z@xxxxxxxxxx>
>Cc: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>; lianglihao@xxxxxxxxxx; Guohanjun (Hanjun Guo) <guohanjun@xxxxxxxxxx>; Chenhaibo (Haibo, OS Lab) <hb.chen@xxxxxxxxxx>; lihao.liang@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
>Subject: Re: [PATCH RFC 01/16] prcu: Add PRCU implementation
>
>On Tue, Jan 30, 2018 at 05:34:03AM +0000, zhangheng (AC) wrote:
>[...]
>> >> > +static void prcu_handler(void *info) {
>> >> > +	struct prcu_local_struct *local;
>> >> > +
>> >> > +	local = this_cpu_ptr(&prcu_local);
>> >> > +	if (!local->locked)
>> >
>> >And I think a smp_mb() is needed here, because in the following case:
>> >
>> >	CPU 0				          CPU 1
>> >	==================		==========================
>> >	{X is initially 0}
>> >
>> >	WRITE_ONCE(X, 1);
>> >
>> >	                      prcu_read_unlock(void):
>> >	                      if (locked) {
>> >	  				              synchronize_prcu(void):
>> >					                ...
>> >					                <send IPI to CPU 0>
>> >	local->locked--;
>> >	                      # switch to IPI
>> > WRITE_ONCE(local->version,....)
>> >	  				            <read CPU 0 version to be latest>
>> >					              <return>
>> >
>> >					              r1 = READ_ONCE(X);
>> >
>> >r1 could be 0, which breaks RCU guarantees.
>> >
>> 
>> Thank you.
>> As I know,
>> it guarantees that the interrupt to be handled after all write instructions issued before have complete in x86 arch.
>> So the smp_mb is meaningless in x86 arch.
>
>Sure. x86 is TSO, and we are talking about reordering of two stores here, and that can not happen on TSO.
>
>> But I am not sure whether other archs guarantee this feature. If not, we do need a smp_mb here.
>> 
>
>I think most of the weak memory model don't have this gaurantee, so you need a smp_mb() or use smp_store_release().

Agree.

>
>> >> > +		WRITE_ONCE(local->version, 
>> >> > +atomic64_read(&prcu->global_version));
>> >> > +}
>> >> > +
>> >> > +void synchronize_prcu(void)
>> >> > +{
>> >> > +	int cpu;
>> >> > +	cpumask_t cpus;
>> >> > +	unsigned long long version;
>> >> > +	struct prcu_local_struct *local;
>> >> > +
>> >> > +	version = atomic64_add_return(1, &prcu->global_version);
>> >> > +	mutex_lock(&prcu->mtx);
>> >> > +
>> >> > +	local = get_cpu_ptr(&prcu_local);
>> >> > +	local->version = version;
>> >> > +	put_cpu_ptr(&prcu_local);
>> >> > +
>> >> > +	cpumask_clear(&cpus);
>> >> > +	for_each_possible_cpu(cpu) {
>> >> > +		local = per_cpu_ptr(&prcu_local, cpu);
>> >> > +		if (!READ_ONCE(local->online))
>> >> > +			continue;
>> >> > +		if (READ_ONCE(local->version) < version) {
>> >> 
>> >> On 32-bit systems, given that ->version is long long, you might see 
>> >> load tearing.  And on some 32-bit systems, the cmpxchg() in
>> >> prcu_hander() might not build.
>> >> 
>> >
>> >/me curious about why an atomic64_t is used here for global version. I think maybe 32bit global version still suffices.
>> >
>> >Regards,
>> >Boqun
>> 
>> Because the synchronization latency is low, it can have higher gp frequency.
>> It seems that 32bit can only correctly work for several years if there are 20+ gps per second.
>> 
>
>Because PRCU doesn't handle gp number overflow? May I ask why this is difficult? Currently RCU could tolerate counter wrap for grace period:
>
>	https://lwn.net/Articles/652677/ (Details in "Parallelism facts of life")
>
>Is there any subtle difference I'm missing?
>
>Regards,
>Boqun
>

Yes, you are right. Currently prcu hasn't given a solution for overflow thus it needs a 64-bit counter.
Giving a solution is not that difficult. I just didn't consider it when I use 64-bit counter.
Since 64-bit counter isn't friendly for 32-bit system, I agree that 32-bit counter + overflow handler is necessary.
Thank you.

>> >
>> >> Or is the idea that only prcu_handler() updates ->version?  But in 
>> >> that case, you wouldn't need the READ_ONCE() above.  What am I missing here?
>> >> 
>> >> > +			smp_call_function_single(cpu, prcu_handler, NULL, 0);
>> >> > +			cpumask_set_cpu(cpu, &cpus);
>> >> > +		}
>> >> > +	}
>> >> > +
>> >> > +	for_each_cpu(cpu, &cpus) {
>> >> > +		local = per_cpu_ptr(&prcu_local, cpu);
>> >> > +		while (READ_ONCE(local->version) < version)
>> >> 
>> >> This ->version read can also tear on some 32-bit systems, and this 
>> >> one most definitely can race with the prcu_handler() above.  Does 
>> >> the algorithm operate correctly in that case?  (It doesn't look 
>> >> that way to me, but I might be missing something.) Or are 32-bit systems excluded?
>> >> 
>> >> > +			cpu_relax();
>> >> > +	}
>> >> 
>> >> I might be missing something, but I believe we need a memory 
>> >> barrier here on non-TSO systems.  Without that, couldn't we miss a preemption?
>> >> 
>> >> > +
>> >> > +	if (atomic_read(&prcu->active_ctr))
>> >> > +		wait_event(prcu->wait_q, !atomic_read(&prcu->active_ctr));
>> >> > +
>> >> > +	mutex_unlock(&prcu->mtx);
>> >> > +}
>> >> > +EXPORT_SYMBOL(synchronize_prcu);
>> >> > +
>> >> > +void prcu_note_context_switch(void) {
>> >> > +	struct prcu_local_struct *local;
>> >> > +
>> >> > +	local = get_cpu_ptr(&prcu_local);
>> >> > +	if (local->locked) {
>> >> > +		atomic_add(local->locked, &prcu->active_ctr);
>> >> > +		local->locked = 0;
>> >> > +	}
>> >> > +	local->online = 0;
>> >> > +	prcu_report(local);
>> >> > +	put_cpu_ptr(&prcu_local);
>> >> > +}
>> >> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 
>> >> > 326d4f88..a308581b 100644
>> >> > --- a/kernel/sched/core.c
>> >> > +++ b/kernel/sched/core.c
>> >> > @@ -15,6 +15,7 @@
>> >> >  #include <linux/init_task.h>
>> >> >  #include <linux/context_tracking.h>  #include 
>> >> > <linux/rcupdate_wait.h>
>> >> > +#include <linux/prcu.h>
>> >> > 
>> >> >  #include <linux/blkdev.h>
>> >> >  #include <linux/kprobes.h>
>> >> > @@ -3383,6 +3384,7 @@ static void __sched notrace __schedule(bool
>> >> > preempt)
>> >> > 
>> >> >  	local_irq_disable();
>> >> >  	rcu_note_context_switch(preempt);
>> >> > +	prcu_note_context_switch();
>> >> > 
>> >> >  	/*
>> >> >  	 * Make sure that signal_pending_state()->signal_pending() 
>> >> > below
>> >> > --
>> >> > 2.14.1.729.g59c0ea183
>> >> > 
>> >> 
>> >
>