| Date | Thu, 6 Sep 2012 10:53:24 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH tip/core/rcu 13/23] rcu: Control grace-period duration from sysfs |
| |
On Thu, Sep 06, 2012 at 04:15:30PM +0200, Peter Zijlstra wrote: > On Thu, 2012-08-30 at 11:18 -0700, Paul E. McKenney wrote: > > From: "Paul E. McKenney" <paul.mckenney@linaro.org> > > > > Some uses of RCU benefit from shorter grace periods, while others benefit > > more from the greater efficiency provided by longer grace periods. > > Therefore, this commit allows the durations to be controlled from sysfs. > > There are two sysfs parameters, one named "jiffies_till_first_fqs" that > > specifies the delay in jiffies from the end of grace-period initialization > > until the first attempt to force quiescent states, and the other named > > "jiffies_till_next_fqs" that specifies the delay (again in jiffies) > > between subsequent attempts to force quiescent states. They both default > > to three jiffies, which is compatible with the old hard-coded behavior. > > A number of questions: > > - how do I know if my workload wants a longer or shorter forced qs > period?
Almost everyone can do just fine with the defaults. If you have more than about 1,000 CPUs, you might need a longer period. Some embedded systems might need a shorter period -- the only specific example I know of is network diagnostic equipment running wireshark, which starts up slowly due to grace-period length.
> - the above implies a measure of good/bad-ness associated with fqs, > can one formulate this?
Maybe. I do not yet have enough data on really big systems to have a good formula just yet.
> - if we can, should we not do this 'automagically' and avoid burdening > our already hard pressed sysads of the world with trying to figure > this out?
I do expect to get there at some point.
> Also, whatever made you want to provide this 'feature' in the first > place?
Complaints from the two groups called out above.
Thanx, Paul
|