Re: [RFC] rcu: Check the range of jiffies_till_xxx_fqs on setting them

From: Byungchul Park
Date: Wed May 30 2018 - 21:27:54 EST



On 2018-05-30 22:49, Paul E. McKenney wrote:
On Wed, May 30, 2018 at 10:06:52PM +0900, Byungchul Park wrote:


On 2018-05-29 21:01, Paul E. McKenney wrote:
On Tue, May 29, 2018 at 04:23:36PM +0900, Byungchul Park wrote:
Hello Paul and folks,

I've thought the code should've been like the below since the range
checking of jiffies_till_first_fqs and jiffies_till_next_fqs everytime
in the loop of rcu_gp_kthread are unnecessary at all. However, it's ok
even if you don't think it's worth doing it.

Nice!

Secondly, I also think jiffies_till_first_fqs = 0 is meaningless so
added checking and adjusting it as what's done on jiffies_till_next_fqs.
Thought?

Actually, jiffies_till_first_fqs == 0 is very useful for cases where
at least one CPU is expected to be idle and grace-period latency is
important. In this case, doing the first scan immediately gets the
dyntick-idle state recorded immediately, getting the idle CPUs out of
the way of the grace period immediately.

Hi Paul~

You might want to handle it through sysfs. Otherwise, we can do it with
force_quiescent_state() IMHO.

I agree that sysfs would be better than debugfs because these parameters
are about tuning, not debugging, so good point!

So why not do this scan as part of grace-period initialization? Because
doing so consumes extra CPU and results in extra cache misses, which is
the opposite of what you want on a completely busy system, especially
one where the CPUs are context switching quickly. Thus no scan during
grace-period initialization.

I am sorry I don't understand this paragraph. :(

Let me try again. ;-)

I could change RCU to avoid the need for jiffies_till_first_fqs == 0,
but doing that would increase CPU consumption for workloads that are
already bottlenecked on the CPU. So I won't be making that change,
so we still need jiffies_till_first_fqs == 0.

Thanks. I see. We need it then.

--
Thanks,
Byungchul