linux-kernel - Re: [RFC] rcu: Check the range of jiffies_till_xxx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 30 May 2018 06:49:52 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Byungchul Park <byungchul.park@....com>
Cc:     jiangshanlai@...il.com, josh@...htriplett.org, rostedt@...dmis.org,
        mathieu.desnoyers@...icios.com, linux-kernel@...r.kernel.org,
        kernel-team@....com, joel@...lfernandes.org
Subject: Re: [RFC] rcu: Check the range of jiffies_till_xxx_fqs on setting
 them

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.

> >But I can see the desire to share code.
> >
> >One approach would be to embed the kernel_params_ops structure inside
> >another structure containing the limits, then just have two structures.
> >Perhaps something like this already exists?  I don't see it right off,
> >but then again, I am not exactly an expert on module_param.
> 
> It would be much nicer if we can as you said. I will check it.

Sounds very good!

							Thanx, Paul

> Thanks a lot Paul.
> 
> -- 
> Thanks,
> Byungchul
>