lkml.org 
[lkml]   [2012]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH tip/core/rcu 13/23] rcu: Control grace-period duration from sysfs
On Thu, Sep 06, 2012 at 08:28:21PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-09-06 at 10:53 -0700, Paul E. McKenney wrote:
>
> > > - 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.
>
> Because the cost of starting a grace period is on the same order (or
> larger) in cost as this period?

Because the overhead of rcu_gp_fqs() can then be multiple jiffies, so
it doesn't make sense to run it so often. If nothing else, the
rcu_gp_kthread() will start chewing up appreciable CPU time.

> > 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.
>
> But but but 3 jiffies.. however is that too long?

Because wireshark startup runs through a great many grace periods when
starting up, and those 3-jiffy time periods add up.

> > > Also, whatever made you want to provide this 'feature' in the first
> > > place?
> >
> > Complaints from the two groups called out above.
>
> Does this really warrant a boot time knob for which even you cannot
> quite explain what values to use when?

If people look at me funny when I explain, I just tell them to leave
it alone.

One alternative at the low end would be to have a sysfs variable that
converted normal grace periods to expedited grace periods. Would that
be preferable?

Thanx, Paul



\
 
 \ /
  Last update: 2012-09-06 23:22    [W:0.374 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site