Compreendendo o RCU ao configurar o kernel do Linux

Question

Estou configurando o kernel do Linux versão 3.9.4. Eu estou sendo perguntado sobre RCU (visto abaixo). Especificamente, quais são essas e quais são as vantagens e desvantagens de ativar ou desativar algumas delas?

Consider userspace as in RCU extended quiescent state (RCU_USER_QS) [N/y/?]
Tree-based hierarchical RCU fanout value (RCU_FANOUT) [64]
Disable tree-based hierarchical RCU auto-balancing (RCU_FANOUT_EXACT) [N/y/?]
Accelerate last non-dyntick-idle CPU's grace periods (RCU_FAST_NO_HZ) [Y/n/?]
Offload RCU callback processing from boot-selected CPUs (RCU_NOCB_CPU) [N/y/?] 

    

Answer 1

Existem alguns detalhes sobre essas opções no site LTTng Project . Os RCUs são (read-copy-update). Essas são estruturas de dados no kernel que permitem que os mesmos dados sejam replicados nos núcleos de uma CPU com vários núcleos e garantem que os dados sejam mantidos em sincronia entre as cópias.

trecho

liburcu is a LGPLv2.1 userspace RCU (read-copy-update) library. This data synchronization library provides read-side access which scales linearly with the number of cores. It does so by allowing multiples copies of a given data structure to live at the same time, and by monitoring the data structure accesses to detect grace periods after which memory reclamation is possible.

Recursos

• Há uma boa referência ao que são os RCUs e como eles funcionam no site lwn.net intitulado: O que é RCU, Fundamentalmente? .
• Há também este recurso com o mesmo título de lwn.net, mas é um conteúdo diferente.
• Há também a entrada da Wikipedia no tópico da RCU também.
• Finalmente, há a documentação do kernel Linux disponível aqui: rcu.txt .

Então, quais são essas opções?

• RCU_USER_QS

This option sets hooks on kernel / userspace boundaries and puts RCU in extended quiescent state when the CPU runs in userspace. It means that when a CPU runs in userspace, it is excluded from the global RCU state machine and thus doesn't try to keep the timer tick on for RCU.

Unless you want to hack and help the development of the full dynticks mode, you shouldn't enable this option. It also adds unnecessary overhead.

If unsure say N

• Fan de RCU

This option controls the fanout of hierarchical implementations of RCU, allowing RCU to work efficiently on machines with large numbers of CPUs. This value must be at least the fourth root of NR_CPUS, which allows NR_CPUS to be insanely large. The default value of RCU_FANOUT should be used for production systems, but if you are stress-testing the RCU implementation itself, small RCU_FANOUT values allow you to test large-system code paths on small(er) systems.

Select a specific number if testing RCU itself. Take the default if unsure.

• RCU_FANOUT_EXACT

This option forces use of the exact RCU_FANOUT value specified, regardless of imbalances in the hierarchy. This is useful for testing RCU itself, and might one day be useful on systems with strong NUMA behavior.

Without RCU_FANOUT_EXACT, the code will balance the hierarchy.

Say N if unsure.

• RCU_FAST_NO_HZ

This option permits CPUs to enter dynticks-idle state even if they have RCU callbacks queued, and prevents RCU from waking these CPUs up more than roughly once every four jiffies (by default, you can adjust this using the rcutree.rcu_idle_gp_delay parameter), thus improving energy efficiency. On the other hand, this option increases the duration of RCU grace periods, for example, slowing down synchronize_rcu().

Say Y if energy efficiency is critically important, and you don't care about increased grace-period durations.

Say N if you are unsure.

• RCU_NOCB_CPU

Use this option to reduce OS jitter for aggressive HPC or real-time workloads. It can also be used to offload RCU callback invocation to energy-efficient CPUs in battery-powered asymmetric multiprocessors.

This option offloads callback invocation from the set of CPUs specified at boot time by the rcu_nocbs parameter. For each such CPU, a kthread ("rcuox/N") will be created to invoke callbacks, where the "N" is the CPU being offloaded, and where the "x" is "b" for RCU-bh, "p" for RCU-preempt, and "s" for RCU-sched. Nothing prevents this kthread from running on the specified CPUs, but (1) the kthreads may be preempted between each callback, and (2) affinity or cgroups can be used to force the kthreads to run on whatever set of CPUs is desired.

Say Y here if you want to help to debug reduced OS jitter. Say N here if you are unsure.

Então você precisa disso?

Eu diria que se você não sabe o que uma opção em particular faz quando compila o kernel então provavelmente é uma aposta segura que você pode viver sem ela. Então eu diria não a essas perguntas.

Além disso, ao fazer este tipo de trabalho, eu normalmente obtenho o arquivo de configuração para o kernel que estou usando com a minha distro e faço uma comparação para ver se estou sem recursos. Este é provavelmente o seu melhor recurso em termos de aprender sobre o que são todas as funcionalidades.

Por exemplo, no Fedora existem exemplos de configuração incluídos aos quais você pode se referir. Dê uma olhada nesta página para mais detalhes: Criando um kernel personalizado .