Kernel - RCU priority boosting

[khz]

Was bringt bzw. hat jemand Erhahrung mit

> General setup > RCU Subsystem > Enable RCU priority boosting

?

Auf welchen Wert habt ihr ihn gestellt?
z.b.

CONFIG_RCU_BOOST_PRIO=99

<-- making it realtime,

CONFIG_RCU_BOOST_DELAY=331

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

 .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.

  ┌────────────── 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.          │

  ┌────── 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/

 

[bluebell]

Ich hab mir mal einen Realtime-Kernel gebastelt, aber am besten laufen halbwegs moderne (3.15) lowlatency-kernel.

Das liegt teilweise an meiner Nutzungsweise. Ich hab oft viele Spuren mit vielen Plugins im Qtractor. Die sind der entscheidende Faktor. Wenn die period size (-p) zu klein ist, damit die CPU alle Plugins abarbeiten kann, dann gibt es halt xruns. Da hilft auch kein noch realtimigeres Realtime

Mit meinem Core i5 und Focusrite Scarlett 2i2 kann ich "nackig" an guten Tagen bis -p64 runtergehen. Nur nutzt mir das in der Praxis gar nichts, weil ich für 30 und mehr Spuren voller Plugins beim Mixen bis auf -p512 hochgehen muss, um nicht gelegentlich xruns zu bekommen.

Qtractor kann die Last der Plugins leider nicht auf mehrere Cores verteilen. Ardour kann das angeblich, aber der ist nicht der Sequenzer meiner Wahl, daher kann ich dazu nichts Fundiertes schreiben.

Ich werde mich nicht weiter in Realtime-Kernel reinknien.