Paul E. McKenney a écrit :
> Fourth cut of "big hammer" expedited RCU grace periods. This uses
> a kthread that schedules itself on all online CPUs in turn, thus
> forcing a grace period. The synchronize_sched(), synchronize_rcu(),
> and synchronize_bh() primitives wake this kthread up and then wait for
> it to force the grace period.
>
> As before, this does nothing to expedite callbacks already registered
> with call_rcu() or call_rcu_bh(), but there is no need to. Just maps
> to synchronize_rcu() and a new synchronize_rcu_bh() on preemptable RCU,
> which has more complex grace-period detection -- this can be fixed later.
>
> Passes light rcutorture testing. Grace periods take around 200
> microseconds on an 8-CPU Power machine. This is a good order of magnitude
> better than v3, but an order of magnitude slower than v2. Furthermore,
> it will get slower the more CPUs you have, and eight CPUs is not all
> that many these days. So this implementation still does not cut it.
>
> Once again, I am posting this on the off-chance that I made some stupid
> mistake that someone might spot. Absent that, I am taking yet another
> different approach, namely setting up per-CPU threads that are awakened
> via smp_call_function(), permitting the quiescent states to be waited
> for in parallel.
>
I dont know, dont we have possibility one cpu is dedicated for the use
of a cpu hungry real time thread ?
krcu_sched_expedited() would dead lock or something ?
> Shortcomings:
>
> o Too slow!!! Thinking in terms of using per-CPU kthreads.
>
> o The wait_event() calls result in 120-second warnings, need
> to use something like wait_event_interruptible(). There are
> probably other corner cases that need attention.
>
> o Does not address preemptable RCU.
>
> Changes since v3:
>
> o Use a kthread that schedules itself on each CPU in turn to
> force a grace period. The synchronize_rcu() primitive
> wakes up the kthread in order to avoid messing with affinity
> masks on user tasks.
>
> o Tried a number of additional variations on the v3 approach, none
> of which helped much.
>
> Changes since v2:
>
> o Use reschedule IPIs rather than a softirq.
>
> Changes since v1:
>
> o Added rcutorture support, and added exports required by
> rcutorture.
>
> o Added comment stating that smp_call_function() implies a
> memory barrier, suggested by Mathieu.
>
> o Added #include for delay.h.
>
> Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
> ---
>
> include/linux/rcuclassic.h | 16 +++
> include/linux/rcupdate.h | 24 ++---
> include/linux/rcupreempt.h | 10 ++
> include/linux/rcutree.h | 13 ++
> kernel/rcupdate.c | 103 +++++++++++++++++++++++
> kernel/rcupreempt.c | 1
> kernel/rcutorture.c | 200 ++++++++++++++++++++++++---------------------
> 7 files changed, 261 insertions(+), 106 deletions(-)
>
> +/*
> + * Kernel thread that processes synchronize_sched_expedited() requests.
> + * This is implemented as a separate kernel thread to avoid the need
> + * to mess with other tasks' cpumasks.
> + */
> +static int krcu_sched_expedited(void *arg)
> +{
> + int cpu;
> +
> + do {
> + wait_event(need_sched_expedited_wq, need_sched_expedited);
> + need_sched_expedited = 0;
> + get_online_cpus();
> + for_each_online_cpu(cpu) {
> + sched_setaffinity(0, &cpumask_of_cpu(cpu));
> + schedule();
<<no return>>
> + }
> + put_online_cpus();
> + sched_expedited_done = 1;
> + wake_up(&sched_expedited_done_wq);
> + } while (!kthread_should_stop());
> + return 0;
> +}
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
