• Paul E. McKenney's avatar
    rcu: Control grace-period duration from sysfs · d40011f6
    Paul E. McKenney authored
    Although almost everyone is well-served by the defaults, some uses of RCU
    benefit from shorter grace periods, while others benefit more from the
    greater efficiency provided by longer grace periods.  Situations requiring
    a large number of grace periods to elapse (and wireshark startup has
    been called out as an example of this) are helped by lower-latency
    grace periods.  Furthermore, in some embedded applications, people are
    willing to accept a small degradation in update efficiency (due to there
    being more of the shorter grace-period operations) in order to gain the
    lower latency.
    
    In contrast, those few systems with thousands of CPUs need longer grace
    periods because the CPU overhead of a grace period rises roughly
    linearly with the number of CPUs.  Such systems normally do not make
    much use of facilities that require large numbers of grace periods to
    elapse, so this is a good tradeoff.
    
    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.
    
    At some future time, it may be possible to automatically increase the
    grace-period length with the number of CPUs, but we do not yet have
    sufficient data to do a good job.  Preliminary data indicates that we
    should add an addiitonal jiffy to each of the delays for every 200 CPUs
    in the system, but more experimentation is needed.  For now, the number
    of systems with more than 1,000 CPUs is small enough that this can be
    relegated to boot-time hand tuning.
    Signed-off-by: default avatarPaul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
    Reviewed-by: default avatarJosh Triplett <josh@joshtriplett.org>
    d40011f6
rcutree.c 88.8 KB