Kernel - RCU priority boosting

[khz]

What about Enable RCU priority boosting?

Which values?
example:

Code: Select all

CONFIG_RCU_BOOST_PRIO=99

<-- making it realtime,

Code: Select all

CONFIG_RCU_BOOST_DELAY=331

<-- using a prime number to avoid reoccurrences, smaller than default=500

Code: Select all

 .config - Linux/x86 3.18.2-gentoo Kernel Configuration
 > General setup > RCU Subsystem ──────────────────────────────────────────────
  ┌───────────────────── Enable RCU priority boosting ──────────────────────┐
  │ CONFIG_RCU_BOOST:                                                       │  
  │                                                                         │  
  │ This option boosts the priority of preempted RCU readers that           │  
  │ block the current preemptible RCU grace period for too long.            │  
  │ This option also prevents heavy loads from blocking RCU                 │  
  │ callback invocation for all flavors of RCU.                             │  
  │                                                                         │  
  │ Say Y here if you are working with real-time apps or heavy loads        │  
  │ Say N here if you are unsure.    

Code: Select all

  ┌────────────── Real-time priority to boost RCU readers to ───────────────┐
  │ CONFIG_RCU_BOOST_PRIO:                                                  │  
  │                                                                         │  
  │ This option specifies the real-time priority to which long-term         │  
  │ preempted RCU readers are to be boosted.  If you are working            │  
  │ with a real-time application that has one or more CPU-bound             │  
  │ threads running at a real-time priority level, you should set           │  
  │ RCU_BOOST_PRIO to a priority higher then the highest-priority           │  
  │ real-time CPU-bound thread.  The default RCU_BOOST_PRIO value           │  
  │ of 1 is appropriate in the common case, which is real-time              │  
  │ applications that do not have any CPU-bound threads.                    │  
  │                                                                         │  
  │ Some real-time applications might not have a single real-time           │  
  │ thread that saturates a given CPU, but instead might have               │  
  │ multiple real-time threads that, taken together, fully utilize          │  
  │ that CPU.  In this case, you should set RCU_BOOST_PRIO to               │  
  │ a priority higher than the lowest-priority thread that is               │  
  │ conspiring to prevent the CPU from running any non-real-time            │  
  │ tasks.  For example, if one thread at priority 10 and another           │  
  │ thread at priority 5 are between themselves fully consuming             │  
  │ the CPU time on a given CPU, then RCU_BOOST_PRIO should be              │  
  │ set to priority 6 or higher.                                            │  
  │                                                                         │  
  │ Specify the real-time priority, or take the default if unsure.          │  
 

Code: Select all

  ┌────── Milliseconds to delay boosting after RCU grace-period start ──────┐
  │ CONFIG_RCU_BOOST_DELAY:                                                 │  
  │                                                                         │  
  │ This option specifies the time to wait after the beginning of           │  
  │ a given grace period before priority-boosting preempted RCU             │  
  │ readers blocking that grace period.  Note that any RCU reader           │  
  │ blocking an expedited RCU grace period is boosted immediately.          │  
  │                                                                         │  
  │ Accept the default if unsure.                                           │  

https://www.kernel.org/doc/Documentation/RCU/rcu.txt
http://www.rdrop.com/users/paulmck/RCU/

[raboof]

Code: Select all

The default RCU_BOOST_PRIO value           │  
  │ of 1 is appropriate in the common case, which is real-time              │  
  │ applications that do not have any CPU-bound threads.                    │  
  │                                                                         │  
  │ Some real-time applications might not have a single real-time           │  
  │ thread that saturates a given CPU, but instead might have               │  
  │ multiple real-time threads that, taken together, fully utilize          │  
  │ that CPU.

I'm not sure, but reading these fragments it might not apply to typical audio workloads: 'we' typically don't saturate the CPU all the time: if we did, we'd have a hard time meeting the latency deadline every period.

But the proof of the pudding... can we measure an effect when tweaking this option?