LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Byungchul Park <byungchul.park@lge.com>
To: paulmck@linux.vnet.ibm.com
Cc: jiangshanlai@gmail.com, josh@joshtriplett.org,
	rostedt@goodmis.org, mathieu.desnoyers@efficios.com,
	linux-kernel@vger.kernel.org, kernel-team@lge.com,
	joel@joelfernandes.org
Subject: Re: [RFC] rcu: Check the range of jiffies_till_xxx_fqs on setting them
Date: Thu, 31 May 2018 10:27:46 +0900	[thread overview]
Message-ID: <158f3434-cb8b-13d9-02d7-f00db177eeaf@lge.com> (raw)
In-Reply-To: <20180530134952.GF7063@linux.vnet.ibm.com>



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

  reply	other threads:[~2018-05-31  1:27 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
2018-05-30 13:49     ` Paul E. McKenney
2018-05-31  1:27       ` Byungchul Park [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=158f3434-cb8b-13d9-02d7-f00db177eeaf@lge.com \
    --to=byungchul.park@lge.com \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=kernel-team@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --subject='Re: [RFC] rcu: Check the range of jiffies_till_xxx_fqs on setting them' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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