On 30/11/2012 20:22, Marc Fournier wrote:
La question est surement bête mais n'y aurait-il pas une bonne raison
pour que le kernel redirige toutes les IRQ sur un seul cœur au-delà de 4
cœurs par processeur ?
C'est ce que je me demande aussi... Les gens qui bossent sur ces parties du
kernel ont quand-même dû réfléchir à la question, non ?
De ce que j'ai compris c'est le comportement par défaut de l'APIC et le
fait que le noyau n'aille pas y mettre son nez derechef peut trouver son
explication dans plusieurs choses.
1. la répartition des IRQ sur les processeurs semble une idée sympa pour
répartir la charge mais se révèle un mauvais choix lorsque le cache des
core est lui aussi réparti puisque on peut se retrouver avec des taux de
cache miss (très couteux) énormes qui vont en fait fortement pénaliser
les perf.
2. il faudrait une bonne dose d'intelligence au noyau pour parvenir à
faire les meilleurs choix d'optimisation, en prenant en compte d'une
part les capacité du processeur (comment est distribué le cache entre
les core, ça varie énormément d'un proc à l'autre), et les capacités
de la carte réseau (MSI-X ou pas), les fonctionnalités complémentaires
apportées en l'absence MSI-X par les patches RPS et RFS de Google, son
propre usage de NAPI ou d'Interrupt Moderation plus ou moins dynamique
sur le hardware.
3. tout ça est peut-être encore un peu spécifique et récent car RPS
et RFS sont intégrés dans le noyau depuis la version 2.6.35 (oui plus
de 2 ans tout de même) ils ne sont pas encore distribués en stable.
Les cartes multi-queues ne sont pas particulièrement grand public, les
PC grand public ne sont pas forcément multi-core.
Enfin même avec beaucoup d'intelligence les dev du noyau on peut-être
préféré conserver la modestie de se dire que l'admin (surtout s'il a
des besoins qui nécessitent de faire ce genre de tuning)était le mieux
placé pour fixer ses priorités, prendre en compte le cas particulier
de son matériel et de ses réglages en passant les bonnes options au
chargement du driver, connaître l'activité de sa machine (besoin d'I/O
disque ou réseau, besoin de libérer certains processeurs, etc.) et
avec tout ça de fixer les priorités (genre : latence VS. bande passante,
gestion de l'énergie, etc.) et de faire la bonne répartition en
fonction de ses besoins.
Finalement il me semble que comme une Debian de base, la répartition des
IRQ sur le core 0 par défaut n'est que base neutre qu'il convient de
modeler en fonction de ses besoins.
En fin de compte peut-être que c'est le status quo qui a été choisi à
défaut d'une solution qui ne pouvais contenter tout le monde, ou bien
un choix du genre économie énergétique, compatibilité parfaite, etc.
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
