LKML Archive on
help / color / mirror / Atom feed
From: Byungchul Park <>
Subject: Re: [RFC] rcu: Check the range of jiffies_till_xxx_fqs on setting them
Date: Wed, 30 May 2018 22:06:52 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.

> 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. :(

> 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.

Thanks a lot Paul.


  reply	other threads:[~2018-05-30 13:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-29  7:23 Byungchul Park
2018-05-29 12:01 ` Paul E. McKenney
2018-05-30 13:06   ` Byungchul Park [this message]
2018-05-30 13:49     ` Paul E. McKenney
2018-05-31  1:27       ` Byungchul Park
2018-05-31  2:18   ` Byungchul Park
2018-05-31  2:51     ` Byungchul Park
2018-05-31 11:17       ` Paul E. McKenney
2018-06-01  1:42         ` Byungchul Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC] rcu: Check the range of jiffies_till_xxx_fqs on setting them' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).