Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
However the "Mark CPU as being in Extended QS" for a CPU in dyntick-idle still gets rescheduled.
Is a dyntick-idle CPU actually a "hold out"?
I thought it was in Extended QS and no further checking/scheduling was required.
So is the arrow to "Send Resched IPI ..." incorrect, or should this be another Quick (or perhaps no so) Quiz?
Hierarchical RCU - state schematic
Posted Nov 6, 2008 19:49 UTC (Thu) by PaulMcKenney (subscriber, #9624)
Now that you mention it, this might indeed be a good quick-quiz candidate. :-)
Posted Nov 7, 2008 1:55 UTC (Fri) by ds2horner (subscriber, #13438)
"CPU passes through QS" and "CPU offline" are considered singleton events, but the "GP too long" is considered a bulk event with all blocking CPUs being addressed.
This, and the explanation of the initiation of the check for the dynaticks state, clarified for me (indeed corrected a misconception I had ) that the dyntick counters are not captured at the beginning of each GP, but only after a "time out" (a reasonable optimization for a low occurrence event).
Speaking of the time out -
in "Detect a Too-Long Grace Period" the "record_gp_stall_check_time() function records the time and also a timestamp set three seconds into the future." timeframe seemed excessive. I believe jiffies was meant (not seconds) which would be consistent with the later reference "A two-jiffies offset helps ensure that CPUs report on themselves when possible".
Each article clarifies details I missed before.
Posted Nov 7, 2008 5:52 UTC (Fri) by PaulMcKenney (subscriber, #9624)
There are indeed two levels of tardiness. Reschedule IPIs are sent to hold-out CPUs after three jiffies, which, in absence of kernel bugs, should end the grace period. These reschedule IPIs are considered "normal" rather than "errors".
There is a separate "error" path enabled by CONFIG_RCU_CPU_STALL_DETECTOR that does in fact have a three-second timeout (recently upped to 10 seconds based on the fact that three-second stalls appear to be present in boot-up code). There is also a three-second-and-two-jiffies timeout as part of this "error" path so that CPUs will normally report on themselves rather than being reported on by others, given that self-reported stack traces are usually more reliable.
Hierarchical RCU - unification suggestion
Posted Nov 7, 2008 15:50 UTC (Fri) by ds2horner (subscriber, #13438)
And now that I hope I believe I understand the process adequately I have a suggestion.
Why not unify the CPU hotplug and "dyntick suspend" status tracking by using the same counter as dyntick for both?
If the CPU offline / online advanced the (now renamed rcu_cpu_awake ( with the LBS matching CPU state)) counter, the even / odd state will satisfy both scenarios.
And I am not advocating this solely for the purpose of reducing the state variables and reducing code (if not complexity):
Conceptually, an offline CPU (a powered down engine which cannot receive interrupts ) is equivalent to a dyntick CPU (powered down state) that receives no interrupts in the grace period.
I realize there are, of course, other reasons to track online/offline CPUs, that the offline check is immediately available.
However, the unification would allow a simpler "no off line" option to the this intended "dyntick replacement" to CLASSIC RCU.
And a simpler "no NO_HZ" option that would be useful for virtual CPUs.
I know - "show me the code!".
OK reading your posts
"v6 scalable classic RCU implementation" "Tue, 23 Sep 2008 16:53:40 -0700"
indicate the magnitude of code that is present to handle a CPU offline activity.
Concerns like moving outstanding rcu work from the "forced" offline CPU to the current CPU, make the offlining distinct.
However, it appears to be performed (at least in this version of the code) just before sending the tardy CPUs the IPI reschedule. Which, back to the schematic, makes it part of the "GP too long" path?
And reading your further post "rcu-state" "Mon, 27 Oct 2008 20:52:01 +0100"
It looks like this version is using a unifying indicator "rcu_cpumode" - still with 2 distinct substates, that are separate from RCU_CPUMODE_PERIODIC which requires the notifications each Grace Period.
How does one keep up?
Posted Nov 8, 2008 1:03 UTC (Sat) by PaulMcKenney (subscriber, #9624)
First, it might well turn out to be the right thing to do. However, the challenges include the following:
At this point, when the code is still just a patch, and therefore subject to change, the only way I can see to keep up is to ask questions. Which you are doing. :-)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds