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.