Network I/O et multi-core
Bonjour à tous, Je m’interroge sur la distribution des I/O réseaux sur un serveur Linux (Debian 6.0.6 ; 2.6.32-5-amd64) : #cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 [..] 29: 3083577549 0 0 0 0 0 0 0 PCI-MSI-edge eth0-rx-0 30: 3016344398 0 0 0 0 0 0 0 PCI-MSI-edge eth0-tx-0 31: 8503469 0 0 0 0 0 0 0 PCI-MSI-edge eth0 32: 30622170 0 0 0 0 0 0 0 PCI-MSI-edge eth1-rx-0 33: 23139539 0 0 0 0 0 0 0 PCI-MSI-edge eth1-tx-0 34: 637808 0 0 0 0 0 0 0 PCI-MSI-edge eth1 Les I/O sont toutes envoyées sur un cœur. Le truc que j’arrive pas à saisir c’est que sur d’autres serveurs avec la même version de noyau, driver réseau (e1000e) et le même genre de cartes réseaux (Intel sur CM Supermicro) ce n’est pas le cas : #cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 53: 2136695 2136042 2138009 2137537 PCI-MSI-edge eth0 54: 42655676 42656495 42654333 42654706 PCI-MSI-edge eth1 J’ai testé « irqbalance » et c’est pas très concluant et pas bien distribué. Vous avez des pistes ou une idée de ces différences ? Benjamin.
Le 28/11/2012 10:38, [WHD-RS] Benjamin SCHILZ a écrit :
Bonjour à tous,
Je m’interroge sur la distribution des I/O réseaux sur un serveur Linux (Debian 6.0.6 ; 2.6.32-5-amd64) :
#cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 [..] 29: 3083577549 0 0 0 0 0 0 0 PCI-MSI-edge eth0-rx-0 30: 3016344398 0 0 0 0 0 0 0 PCI-MSI-edge eth0-tx-0 31: 8503469 0 0 0 0 0 0 0 PCI-MSI-edge eth0 32: 30622170 0 0 0 0 0 0 0 PCI-MSI-edge eth1-rx-0 33: 23139539 0 0 0 0 0 0 0 PCI-MSI-edge eth1-tx-0 34: 637808 0 0 0 0 0 0 0 PCI-MSI-edge eth1
Les I/O sont toutes envoyées sur un cœur. Le truc que j’arrive pas à saisir c’est que sur d’autres serveurs avec la même version de noyau, driver réseau (e1000e) et le même genre de cartes réseaux (Intel sur CM Supermicro) ce n’est pas le cas :
#cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 53: 2136695 2136042 2138009 2137537 PCI-MSI-edge eth0 54: 42655676 42656495 42654333 42654706 PCI-MSI-edge eth1
J’ai testé « irqbalance » et c’est pas très concluant et pas bien distribué.
Vous avez des pistes ou une idée de ces différences ?
Benjamin.
APIC est configuré de la même façon ? Cela peut-être très BIOS spécifique... Cdlt,
Bonjour Benjamin, Est-ce la même distribution entre les 2 serveurs (Debian 6.0.6) ? Il ne semble que le patch de Google sur la répartition des IO réseau sur différents coeurs de CPU n'a été intégré que dans le 2.6.35. La plupart des distributions ont fait un backport de ce patch, mais pas toutes. Florian 2012/11/28 <jean-yves@lenhof.eu.org>
Le 28/11/2012 10:38, [WHD-RS] Benjamin SCHILZ a écrit :
Bonjour à tous,
Je m’interroge sur la distribution des I/O réseaux sur un serveur Linux (Debian 6.0.6 ; 2.6.32-5-amd64) :
#cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 [..] 29: 3083577549 0 0 0 0 0 0 0 PCI-MSI-edge eth0-rx-0 30: 3016344398 0 0 0 0 0 0 0 PCI-MSI-edge eth0-tx-0 31: 8503469 0 0 0 0 0 0 0 PCI-MSI-edge eth0 32: 30622170 0 0 0 0 0 0 0 PCI-MSI-edge eth1-rx-0 33: 23139539 0 0 0 0 0 0 0 PCI-MSI-edge eth1-tx-0 34: 637808 0 0 0 0 0 0 0 PCI-MSI-edge eth1
Les I/O sont toutes envoyées sur un cœur. Le truc que j’arrive pas à saisir c’est que sur d’autres serveurs avec la même version de noyau, driver réseau (e1000e) et le même genre de cartes réseaux (Intel sur CM Supermicro) ce n’est pas le cas :
#cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 53: 2136695 2136042 2138009 2137537 PCI-MSI-edge eth0 54: 42655676 42656495 42654333 42654706 PCI-MSI-edge eth1
J’ai testé « irqbalance » et c’est pas très concluant et pas bien distribué.
Vous avez des pistes ou une idée de ces différences ?
Benjamin.
APIC est configuré de la même façon ? Cela peut-être très BIOS spécifique...
Cdlt,
______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
2012/11/28 [WHD-RS] Benjamin SCHILZ <benjamin@whd-rs.com>:
Bonjour à tous,
Je m’interroge sur la distribution des I/O réseaux sur un serveur Linux (Debian 6.0.6 ; 2.6.32-5-amd64) :
Les I/O sont toutes envoyées sur un cœur. Le truc que j’arrive pas à saisir c’est que sur d’autres serveurs avec la même version de noyau, driver réseau (e1000e) et le même genre de cartes réseaux (Intel sur CM Supermicro) ce n’est pas le cas :
#cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 53: 2136695 2136042 2138009 2137537 PCI-MSI-edge eth0 54: 42655676 42656495 42654333 42654706 PCI-MSI-edge eth1
Bonjour, C'est lié au nombre de coeurs et à l'architecture physique de la carte mère. J'ai constaté qu'au delà de 4 coeurs, les interruptions sont wirées sur un coeur et plus distribuées (pour les fans, lire ce qui concerne l'io-apic dans le noyau). irqbalance est à oublier, vu qu'il cherche l'économie d'énergie et pas la performance apparemment. Enfin, il ne fonctionne tout simplement pas quand on renomme les cartes (si ça ne commence pas par eth il est perdu). Perso j'ai fait des scripts dans le ifup.d qui redistribue les IRQs réseau en round-robin sur tous mes coeurs (je les matche avec une regex). Il peut y avoir un intérêt à mettre plus de cartes en LACP par exemple, même si pas beaucoup de débit, pour utiliser tous les coeurs (je pense à un LB en DSR par exemple); et à des cartes genre intel ou broadcom qui ont 8 files txrx avec chacune une interruption. Cordialement, -- Aurélien Guillaume
Le 28/11/2012 11:14, Aurélien a écrit :
2012/11/28 [WHD-RS] Benjamin SCHILZ <benjamin@whd-rs.com>:
Bonjour à tous,
Je m’interroge sur la distribution des I/O réseaux sur un serveur Linux (Debian 6.0.6 ; 2.6.32-5-amd64) :
Les I/O sont toutes envoyées sur un cœur. Le truc que j’arrive pas à saisir c’est que sur d’autres serveurs avec la même version de noyau, driver réseau (e1000e) et le même genre de cartes réseaux (Intel sur CM Supermicro) ce n’est pas le cas :
#cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 53: 2136695 2136042 2138009 2137537 PCI-MSI-edge eth0 54: 42655676 42656495 42654333 42654706 PCI-MSI-edge eth1
Bonjour,
C'est lié au nombre de coeurs et à l'architecture physique de la carte mère. J'ai constaté qu'au delà de 4 coeurs, les interruptions sont wirées sur un coeur et plus distribuées (pour les fans, lire ce qui concerne l'io-apic dans le noyau).
irqbalance est à oublier, vu qu'il cherche l'économie d'énergie et pas la performance apparemment. Enfin, il ne fonctionne tout simplement pas quand on renomme les cartes (si ça ne commence pas par eth il est perdu). Perso j'ai fait des scripts dans le ifup.d qui redistribue les IRQs réseau en round-robin sur tous mes coeurs (je les matche avec une regex).
Il peut y avoir un intérêt à mettre plus de cartes en LACP par exemple, même si pas beaucoup de débit, pour utiliser tous les coeurs (je pense à un LB en DSR par exemple); et à des cartes genre intel ou broadcom qui ont 8 files txrx avec chacune une interruption.
Cordialement, Bonjour,
Problème que j'ai aussi pu rencontrer de mon coté (même sur des kernels 3.2 de squeeze-backports, que je recommande en passant par rapport à un kernel 2.6.32 pour des machines à forte charge réseau ou avec matériel récent), irqbalance de son côté étant parfois totalement inefficace, parfois ne proposant pas une répartition idéale. A ne pas oublier qu'il est recommandé de n'envoyer les interrupts que vers les cœurs physiques et non pas vers les cœurs logiques (hyper threading) du/des CPU(s) et qu'irqbalance ne prends pas ce paramètre en compte. Personnellement, je force la répartition manuellement dans le /etc/rc.local, ça n'est peut être pas très propre mais ça fonctionne sans soucis (ne pas oublier de revérifier que les numéros d'interrupts n'aient pas changés pour les périphériques suite à un changement de kernel par exemple ou scripter pour automatiser cela), pour plus de détails sur le format de la valeur à utiliser (possibilité d'envoyer les interrupts vers plusieurs cœurs en même temps et non pas seulement vers un seul) : https://cs.uwaterloo.ca/~brecht/servers/apic/SMP-affinity.txt ps: il est aussi intéressant de faire de même pour les cartes RAID si applicable, de plus certaines cartes permettent également d'être vues en plusieurs "parties" dans la liste des devices afin de pouvoir mieux répartir la charge (ex: http://kb.lsi.com/KnowledgebaseArticle16667.aspx). Cordialement.
Problème que j'ai aussi pu rencontrer de mon coté (même sur des kernels 3.2 de squeeze-backports, que je recommande en passant par rapport à un kernel 2.6.32 pour des machines à forte charge réseau ou avec matériel récent) Effectivement monter en version sur le kernel serait intéressant. Dans ce cas pourquoi ne pas partir directement sur un 3.6.8 compilé ? au niveau gestion réseau les kernels récents doivent avoir de nouvelles optimisations ?
A ne pas oublier qu'il est recommandé de n'envoyer les interrupts que vers les cœurs physiques et non pas vers les cœurs logiques C'est noté.
Personnellement, je force la répartition manuellement dans le /etc/rc.local, ça n'est peut être pas très propre mais ça fonctionne sans soucis (ne pas oublier de revérifier que les numéros d'interrupts n'aient pas changés pour les périphériques suite à un changement de kernel par exemple ou scripter pour automatiser cela), pour plus de détails sur le format de la valeur à utiliser (possibilité d'envoyer les interrupts vers plusieurs cœurs en même temps et non pas seulement vers un seul) : https://cs.uwaterloo.ca/~brecht/servers/apic/SMP-affinity.txt Merci.
ps: il est aussi intéressant de faire de même pour les cartes RAID si applicable, de plus certaines cartes permettent également d'être vues en plusieurs "parties" dans la liste des devices afin de pouvoir mieux répartir la charge (ex: http://kb.lsi.com/KnowledgebaseArticle16667.aspx). Pas pensé à ça, à creuser.
C'est lié au nombre de coeurs et à l'architecture physique de la carte mère. J'ai constaté qu'au delà de 4 coeurs, les interruptions sont wirées sur un coeur et plus distribuées (pour les fans, lire ce qui concerne l'io-apic dans le noyau) Effectivement, sur une machine 2 cœurs c'est distribué, sur une 4 cœurs aussi, et sur une 4 cœurs (8 threads) c'est bloqué sur un cœur.
irqbalance est à oublier, vu qu'il cherche l'économie d'énergie et pas la performance apparemment. Enfin, il ne fonctionne tout simplement pas quand on renomme les cartes (si ça ne commence pas par eth il est perdu). Ok, d'ailleurs la version dans Debian Squeeze semble assez ancienne.
Perso j'ai fait des scripts dans le ifup.d qui redistribue les IRQs réseau en round-robin sur tous mes coeurs (je les matche avec une regex). Un petit exemple ;)
Il peut y avoir un intérêt à mettre plus de cartes en LACP par exemple, même si pas beaucoup de débit, pour utiliser tous les coeurs (je pense à un LB en DSR par exemple); et à des cartes genre intel ou broadcom qui ont 8 files txrx avec chacune une interruption.
Effectivement c'est intéressant, dans mon cas c'est un LB en DSR justement.
2012/11/28 [WHD-RS] Benjamin SCHILZ <benjamin@whd-rs.com>:
Perso j'ai fait des scripts dans le ifup.d qui redistribue les IRQs réseau en round-robin sur tous mes coeurs (je les matche avec une regex). Un petit exemple ;)
Allez, câdo, drop in /etc/network/if-up.d et chmod +x, et ifdown/ifup une des cartes. Y'a sûrement mieux à faire, mais ça marche bien pour moi. Le mieux que j'ai trouvé c'est 3 cartes réseaux intel 8 files en LAG LACP pour 24 coeurs sur mon matériel. La regex est sûrement à tuner. #!/bin/bash # This script balances the interrupts statically. # It only touches the interrupts specified by this regular expressions (grepped in /proc/interrupts) # Only active interrupts will be grepped, so please re-run the script on post-up. NETWORK_INTERRUPTS=' (gbe|bnx|eth|igb)[0-9]+(-TxRx)?-[0-7]$' # Balance the interrupts on all the cores, in round-robin fashion. total_cores=$(cat /proc/cpuinfo | grep '^processor' | wc -l) interrupts=$(cat /proc/interrupts | egrep "${NETWORK_INTERRUPTS}" | awk -F: "{ print \$1 }" | tr '\n' ' ') let current_core=0; for irq in ${interrupts}; do affinity="$(printf "%08x" $((1 << ($current_core % $total_cores))))" # echo "IRQ #${irq} will have affinity to ${affinity}" echo "${affinity}" > "/proc/irq/${irq}/smp_affinity" let current_core=$(($current_core+1)) done -- Aurélien Guillaume
Le 28/11/2012 14:16, Aurélien a écrit :
Allez, câdo, drop in /etc/network/if-up.d et chmod +x, et ifdown/ifup une des cartes. Y'a sûrement mieux à faire, mais ça marche bien pour moi. Le mieux que j'ai trouvé c'est 3 cartes réseaux intel 8 files en LAG LACP pour 24 coeurs sur mon matériel. La regex est sûrement à tuner.
#!/bin/bash
# This script balances the interrupts statically.
# It only touches the interrupts specified by this regular expressions (grepped in /proc/interrupts) # Only active interrupts will be grepped, so please re-run the script on post-up.
NETWORK_INTERRUPTS=' (gbe|bnx|eth|igb)[0-9]+(-TxRx)?-[0-7]$'
# Balance the interrupts on all the cores, in round-robin fashion. total_cores=$(cat /proc/cpuinfo | grep '^processor' | wc -l) interrupts=$(cat /proc/interrupts | egrep "${NETWORK_INTERRUPTS}" | awk -F: "{ print \$1 }" | tr '\n' ' ')
let current_core=0; for irq in ${interrupts}; do affinity="$(printf "%08x" $((1 << ($current_core % $total_cores))))" # echo "IRQ #${irq} will have affinity to ${affinity}" echo "${affinity}" > "/proc/irq/${irq}/smp_affinity" let current_core=$(($current_core+1)) done Une alternative en mksh qui doit aussi marcher sous ksh93 mais à vérifier ne faisant appel qu'à egrep en commande externe pour récupérer le nombre de coeurs physiques du CPU, en codant le script proprement on peux également se débarrasser de l'utilisation de egrep :
#!/bin/mksh IFS=" " set -A MAXCORE $(egrep -m1 "^cpu cores" /proc/cpuinfo) MAXCORE="${MAXCORE[2]}" c=0 l=0 IFS=$'\n' while (( ++l < 100 )); do IFS=" " read -t2 -A || break if [[ "$l" = 1 ]]; then COLNUM="$((${#REPLY[*]}+2))" else if [[ "${REPLY[${COLNUM}]}" = @(gbe|bnx|eth|igb)+([0-9])* ]]; then printf "%08x" $((1 << ($c % ${MAXCORE}))) > /proc/irq/${REPLY[0]%:}/smp_affinity ((++c)) fi fi done < "/proc/interrupts" Par contre, le maxcore ne prends pas en compte la possibilité d'avoir plusieurs CPU physiques sur une même machine.
On Wed, Nov 28, 2012 at 3:48 PM, Jean Weisbuch <jean@plusquenet.net> wrote:
Une alternative en mksh qui doit aussi marcher sous ksh93 mais à vérifier ne faisant appel qu'à egrep en commande externe pour récupérer le nombre de cœurs physiques du CPU, en codant le script proprement on peux également se débarrasser de l'utilisation de egrep :
Et printf, ou bien c'est une builtin ? En tout cas je concède que c'est codé à l'arrache (déjà y'a des cat | :)). Mais vs bash, mksh ça fait une dép en plus non ? Il y a un intérêt particulier que je n'aurais pas vu ? -- Aurélien Guillaume
Le 28/11/2012 17:47, Aurélien a écrit :
On Wed, Nov 28, 2012 at 3:48 PM, Jean Weisbuch <jean@plusquenet.net> wrote:
Une alternative en mksh qui doit aussi marcher sous ksh93 mais à vérifier ne faisant appel qu'à egrep en commande externe pour récupérer le nombre de cœurs physiques du CPU, en codant le script proprement on peux également se débarrasser de l'utilisation de egrep :
Et printf, ou bien c'est une builtin ? En tout cas je concède que c'est codé à l'arrache (déjà y'a des cat | :)). Mais vs bash, mksh ça fait une dép en plus non ? Il y a un intérêt particulier que je n'aurais pas vu ?
printf n'est "normallement" pas builtin dans mksh (en le compilant avec les options par défaut) mais les versions packagées pour Debian ont le printf builtin d'activé (vérifiable avec "whence printf" : renvoie le chemin de printf si non builtin, sinon renvoie "printf") donc oui, ça n'est effectivement pas "propre". La doc de mksh à propos de printf (https://www.mirbsd.org/htman/i386/man1/mksh.htm) : Formatted output. Approximately the same as the printf(1), utili- ty, except it uses the same Backslash expansion and I/O code as the rest of mksh. This is not normally part of mksh; however, dis- tributors may have added this as builtin as a speed hack. Do not use in new code. Voici le bout de code qui remplace la ligne utilisant printf dans la version initiale du script (sachant qu'en plus j'avais oublié de prendre en compte le nombre de CPU dans le printf, ce qui est résolu ici) : typeset -Uui16 -Z$((3+MAXCORE)) i; ((i = 1 << (c % MAXCORE))) print "${i#16#}" > /proc/irq/${REPLY%:}/smp_affinity Quant à la dépendance à mksh, le script dans sa version avec printf devrait pouvoir aussi tourner sous ksh93 et autres variantes de ksh (l'utilisation des paramètres avancés du typeset sur la "nouvelle version" ne pas passera pas sous ksh93). Pour ceux qui ne connaitraient pas mksh, c'est un shell léger et rapide (souvent aussi rapide voire plus que (d)ash mais avec bien plus de fonctionnalités et moins de bugs). De plus c'est un shell disponible sur de très nombreux systèmes/architectures (c'est d'ailleurs devenu le shell par défaut d'Android) et qui est encore activement développé et n'ayant quasi aucune dépendance (les dernières versions peuvent être compilées et fonctionner sur Debian 0.x si mes souvenirs sont bons et une version pour Windows existe également). Il respecte mieux les normes POSIX que la plupart des shells et peut être utilisé pour /bin/sh (avec /bin/mksh-static) et /bin/ksh (de rares fonctions de ksh93 ne sont pas (encore) disponibles tel que les tableaux associatifs). Personnellement, je fais installer mksh automatiquement sur toutes mes install (en version squeeze-backports sous Squeeze, la 40.4+ étant plus véloce et offrant quelques possibilités en plus par rapport à la 39.3), sachant que le mainteneur des packages Debian et Ubuntu n'est autre que le développeur principal du shell (qui est facilement "accessible" sur IRC et très sympathique).
Le 28/11/2012 14:16, Aurélien a écrit :
Allez, câdo, drop in /etc/network/if-up.d et chmod +x, et ifdown/ifup une des cartes. Y'a sûrement mieux à faire, mais ça marche bien pour moi. Le mieux que j'ai trouvé c'est 3 cartes réseaux intel 8 files en LAG LACP pour 24 coeurs sur mon matériel. La regex est sûrement à tuner.
#!/bin/bash
# This script balances the interrupts statically.
# It only touches the interrupts specified by this regular expressions (grepped in /proc/interrupts) # Only active interrupts will be grepped, so please re-run the script on post-up.
NETWORK_INTERRUPTS=' (gbe|bnx|eth|igb)[0-9]+(-TxRx)?-[0-7]$'
# Balance the interrupts on all the cores, in round-robin fashion. total_cores=$(cat /proc/cpuinfo | grep '^processor' | wc -l) interrupts=$(cat /proc/interrupts | egrep "${NETWORK_INTERRUPTS}" | awk -F: "{ print \$1 }" | tr '\n' ' ')
let current_core=0; for irq in ${interrupts}; do affinity="$(printf "%08x" $((1 << ($current_core % $total_cores))))" # echo "IRQ #${irq} will have affinity to ${affinity}" echo "${affinity}" > "/proc/irq/${irq}/smp_affinity" let current_core=$(($current_core+1)) done
Petit retour sur le script, déjà merci, j'avais déjà vu passer des infos à ce sujet mais je ne m'étais pas encore penché sur cette optimisation. Pour ma part sur une Debian avec kernel 3.4.19 la regexp ne marche pas. Voilà ce que j'ai dans le interrupts pour eth0 par exemple CPU0 CPU1 307: 116542899 0 xen-pirq-msi-x eth0-rx-0 308: 98413431 0 xen-pirq-msi-x eth0-rx-1 309: 160018027 0 xen-pirq-msi-x eth0-tx-0 310: 88439060 0 xen-pirq-msi-x eth0-tx-1 J'ai modifié la regexp comme cela (gbe|bnx|eth|igb)[0-9]+-(tx|rx)-[0-7]$ Par contre avant d'appliquer la modification j'ai trouvé une valeur à 3 dans le /proc/irq/(307-310)/smp_affinity La machine est un xeon 4 core 8 en HT qui héberge du xen où j'ai spécialement réservé 2 core pour l'hyperviseur. Du coup la valeur 3 m'interpelle un peu sachant que cela devrait être 1 ou 2 comme le confirme d'ailleurs /proc/irq/307/smp_affinity_list 1-2 Par contre une fois les modifications appliquées j'ai /proc/irq/(307-310)/smp_affinity_list à 0 ou 1 /proc/irq/(307-310)/smp_affinity à 1 ou 2 Depuis que j'ai fait la modification j'ai bien le cpu1 qui bosse pour les irq donnés 307: 116646799 0 xen-pirq-msi-x eth0-rx-0 308: 98452617 46945 xen-pirq-msi-x eth0-rx-1 309: 160194164 0 xen-pirq-msi-x eth0-tx-0 310: 88450878 16109 xen-pirq-msi-x eth0-tx-1
2012/11/28 Wallace <wallace@morkitu.org>:
Pour ma part sur une Debian avec kernel 3.4.19 la regexp ne marche pas. Voilà ce que j'ai dans le interrupts pour eth0 par exemple
La regex marche chez moi, mais effectivement, je l'ai faite pour mes cartes. Elle est à tuner pour VMWare par ex.
CPU0 CPU1 307: 116542899 0 xen-pirq-msi-x eth0-rx-0 308: 98413431 0 xen-pirq-msi-x eth0-rx-1 309: 160018027 0 xen-pirq-msi-x eth0-tx-0 310: 88439060 0 xen-pirq-msi-x eth0-tx-1
J'ai modifié la regexp comme cela (gbe|bnx|eth|igb)[0-9]+-(tx|rx)-[0-7]$
Par contre avant d'appliquer la modification j'ai trouvé une valeur à 3 dans le /proc/irq/(307-310)/smp_affinity
Oui, par défaut c'est activé sur tous les cores MAIS quand on en a plus de 8, en fait la redistribution est fixe (Physical interrupt routing ou un truc du genre).
La machine est un xeon 4 core 8 en HT qui héberge du xen où j'ai spécialement réservé 2 core pour l'hyperviseur. Du coup la valeur 3 m'interpelle un peu sachant que cela devrait être 1 ou 2 comme le confirme d'ailleurs /proc/irq/307/smp_affinity_list 1-2
Bah 3 c'est 1+2 ou "(core 1)(core 0)=11" en binaire non ?
Par contre une fois les modifications appliquées j'ai /proc/irq/(307-310)/smp_affinity_list à 0 ou 1 /proc/irq/(307-310)/smp_affinity à 1 ou 2
Depuis que j'ai fait la modification j'ai bien le cpu1 qui bosse pour les irq donnés 307: 116646799 0 xen-pirq-msi-x eth0-rx-0 308: 98452617 46945 xen-pirq-msi-x eth0-rx-1 309: 160194164 0 xen-pirq-msi-x eth0-tx-0 310: 88450878 16109 xen-pirq-msi-x eth0-tx-1
Cool ^^ D'ailleurs si quelqu'un sait si le nombre d'interrupts par carte est reglable sous VMWare, ça m'intéresse ! Cordialement, -- Aurélien Guillaume
Il faut activer les patchs de Google RPS et RFS qui permettent d'avoir du multiqueues sur des cartes réseau cheap: http://lwn.net/Articles/398393/ Il faut donc au minimum le kernel 2.6.35 (mais les suivants ont leur lot d'amélioration) puis activer le multiqueue : http://alouche.net/2010/08/24/rps-and-rfs-kernel-network-stack/ Testé, validé, et en prod depuis la sortie du 2.6.35 ;) Le 28 novembre 2012 19:26, Aurélien <footplus@gmail.com> a écrit :
2012/11/28 Wallace <wallace@morkitu.org>:
Pour ma part sur une Debian avec kernel 3.4.19 la regexp ne marche pas. Voilà ce que j'ai dans le interrupts pour eth0 par exemple
La regex marche chez moi, mais effectivement, je l'ai faite pour mes cartes. Elle est à tuner pour VMWare par ex.
CPU0 CPU1 307: 116542899 0 xen-pirq-msi-x eth0-rx-0 308: 98413431 0 xen-pirq-msi-x eth0-rx-1 309: 160018027 0 xen-pirq-msi-x eth0-tx-0 310: 88439060 0 xen-pirq-msi-x eth0-tx-1
J'ai modifié la regexp comme cela (gbe|bnx|eth|igb)[0-9]+-(tx|rx)-[0-7]$
Par contre avant d'appliquer la modification j'ai trouvé une valeur à 3 dans le /proc/irq/(307-310)/smp_affinity
Oui, par défaut c'est activé sur tous les cores MAIS quand on en a plus de 8, en fait la redistribution est fixe (Physical interrupt routing ou un truc du genre).
La machine est un xeon 4 core 8 en HT qui héberge du xen où j'ai spécialement réservé 2 core pour l'hyperviseur. Du coup la valeur 3 m'interpelle un peu sachant que cela devrait être 1 ou 2 comme le confirme d'ailleurs /proc/irq/307/smp_affinity_list 1-2
Bah 3 c'est 1+2 ou "(core 1)(core 0)=11" en binaire non ?
Par contre une fois les modifications appliquées j'ai /proc/irq/(307-310)/smp_affinity_list à 0 ou 1 /proc/irq/(307-310)/smp_affinity à 1 ou 2
Depuis que j'ai fait la modification j'ai bien le cpu1 qui bosse pour les irq donnés 307: 116646799 0 xen-pirq-msi-x eth0-rx-0 308: 98452617 46945 xen-pirq-msi-x eth0-rx-1 309: 160194164 0 xen-pirq-msi-x eth0-tx-0 310: 88450878 16109 xen-pirq-msi-x eth0-tx-1
Cool ^^
D'ailleurs si quelqu'un sait si le nombre d'interrupts par carte est reglable sous VMWare, ça m'intéresse !
Cordialement, -- Aurélien Guillaume _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Greg
J'ai le RPS et RFS présent dans la compile du 3.6.7 mais j'ai rien sur //sys/class/net/eth0/rps_cpus/ comme marqué dans les docs... du coup je ne sais pas. CONFIG_RPS=y CONFIG_RFS_ACCEL=y Le 28/11/2012 20:55, Greg a écrit :
Il faut activer les patchs de Google RPS et RFS qui permettent d'avoir du multiqueues sur des cartes réseau cheap: http://lwn.net/Articles/398393/
Il faut donc au minimum le kernel 2.6.35 (mais les suivants ont leur lot d'amélioration) puis activer le multiqueue : http://alouche.net/2010/08/24/rps-and-rfs-kernel-network-stack/
Testé, validé, et en prod depuis la sortie du 2.6.35 ;)
Le 28/11/2012 19:26, Aurélien a écrit :
La machine est un xeon 4 core 8 en HT qui héberge du xen où j'ai spécialement réservé 2 core pour l'hyperviseur. Du coup la valeur 3 m'interpelle un peu sachant que cela devrait être 1 ou 2 comme le confirme d'ailleurs /proc/irq/307/smp_affinity_list 1-2 Bah 3 c'est 1+2 ou "(core 1)(core 0)=11" en binaire non ? J'y ai pensé mais dans ce cas dans les stats j’aurais eu bien les deux cpu qui bossent ensemble et ce n'était pas le cas.
Cool ^^
D'ailleurs si quelqu'un sait si le nombre d'interrupts par carte est reglable sous VMWare, ça m'intéresse ! On virtualise open source par chez nous :D
2012/11/29 Wallace <wallace@morkitu.org>:
Le 28/11/2012 19:26, Aurélien a écrit :
La machine est un xeon 4 core 8 en HT qui héberge du xen où j'ai spécialement réservé 2 core pour l'hyperviseur. Du coup la valeur 3 m'interpelle un peu sachant que cela devrait être 1 ou 2 comme le confirme d'ailleurs /proc/irq/307/smp_affinity_list 1-2 Bah 3 c'est 1+2 ou "(core 1)(core 0)=11" en binaire non ? J'y ai pensé mais dans ce cas dans les stats j’aurais eu bien les deux cpu qui bossent ensemble et ce n'était pas le cas.
Il explique mieux que moi: http://www.alexonlinux.com/why-interrupt-affinity-with-multiple-cores-is-not... http://www.alexonlinux.com/smp-affinity-and-proper-interrupt-handling-in-lin... Cordialement, -- Aurélien Guillaume
Bonjour,
C'est lié au nombre de coeurs et à l'architecture physique de la carte mère. J'ai constaté qu'au delà de 4 coeurs, les interruptions sont wirées sur un coeur et plus distribuées (pour les fans, lire ce qui concerne l'io-apic dans le noyau).
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 ? Cordialement, *Stéphane*
Excerpts from Stéphane Diacquenod's message of 2012-11-29 21:59:20 +0100:
Bonjour,
C'est lié au nombre de coeurs et à l'architecture physique de la carte mère. J'ai constaté qu'au delà de 4 coeurs, les interruptions sont wirées sur un coeur et plus distribuées (pour les fans, lire ce qui concerne l'io-apic dans le noyau).
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 ? Un argument en faveur d'une répartition inégale des tâches entre les CPUs, c'est que les coeurs peu/pas utilisés chauffent moins et consomment moins d'énergie. Je suppose que pour des gros clusters, ça peut faire une différence sur la facture d'électricité à la fin du mois ? À+, Marc
2012/11/30 Marc Fournier <marc.fournier@camptocamp.com>:
Excerpts from Stéphane Diacquenod's message of 2012-11-29 21:59:20 +0100:
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 ?
Un argument en faveur d'une répartition inégale des tâches entre les CPUs, c'est que les coeurs peu/pas utilisés chauffent moins et consomment moins d'énergie. Je suppose que pour des gros clusters, ça peut faire une différence sur la facture d'électricité à la fin du mois ?
Bah je sais pas trop, en tout cas j'ai des machines en prod qui passeraient 100% de 1 seul coeur à faire des I/O si je n'avais rien qui tournait. IRQBalance améliore un peu la chose mais c'est pas encore ça (pas vraiment "fair"), et surtout il est useless si les interfaces ont été renommées (il matche plus que c'est des IRQs qui doivent être rebalancées. Si on distribue bien, et si on dispose de suffisamment de files TxRx hardware ou du patch de google, on peut utiliser tous les coeurs à faire des I/Os réseaux. Je pense toutefois que cela n'intéresse que les personnes avidement à la recherche de performances réseau (load-balancers, etc). -- Aurélien
Le 30/11/2012 20:22, Marc Fournier a écrit :
Excerpts from Stéphane Diacquenod's message of 2012-11-29 21:59:20 +0100:
Bonjour,
C'est lié au nombre de coeurs et à l'architecture physique de la carte mère. J'ai constaté qu'au delà de 4 coeurs, les interruptions sont wirées sur un coeur et plus distribuées (pour les fans, lire ce qui concerne l'io-apic dans le noyau). 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 ?
Un argument en faveur d'une répartition inégale des tâches entre les CPUs, c'est que les coeurs peu/pas utilisés chauffent moins et consomment moins d'énergie. Je suppose que pour des gros clusters, ça peut faire une différence sur la facture d'électricité à la fin du mois ?
À+, Marc _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
J'ai déjà eu le cas de machines servant de load balancer qui en cas de flood (se retrouvant à avoir du fort traffic sur deux interfaces réseau différentes) se retrouvaient avec le premier cœur CPU utilisé à 100% par sur CPU SI (System Interrupt), bloquant complètement la machine à la manière d'un load CPU IOWait à 100% par exemple, répartir sur plusieurs coeurs les interrupts avait permis "d'absorber" le traffic sans bloquer la machine. C'est également intéressant sur les machines servant de routeur et ayant de nombreuses interfaces réseaux, l'utilité d'avoir plusieurs CPU physiques peux se faire sentir en cas de trafic important. Ce n'est probablement pas la configuration par défaut car cela n'est pas "optimum" d'un point de vue énergétique (garder tout les cœurs actifs en cas de seule activité réseau au lieu d'un seul) et il n'est pas possible d'équilibrer automatiquement "sur mesure", sachant qu'il peux y avoir plus d'interrupts à balancer que de cœurs CPU, histoire de ne pas se retrouver à mettre les deux plus gros consommateurs sur le même cœur il faut faire manuellement la répartition.
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.
Sylvain Vallerot <sylvain@gixe.net> : [...]
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
A ce sujet, le 8168c de Realtek est sensé prendre en charge deux (!) files en RSS. Il a souvent été inclus dans des cartes mères grand public - Asus, Gigabyte, etc. - depuis environ 2007. Aujourd'hui on trouve plutôt du 8168e(vl) ou au delà. On ne va évidemment pas loin avec deux files mais si quelqu'un est prêt à crasher une machine à répétition, je dois pouvoir faire quelque chose pour le 8168c. Ce serait un début, peut être suffisant pour inciter Realtek à fournir quelques informations relatives au 8168f et à ses quatre files. -- Ueimor
participants (11)
-
[WHD-RS] Benjamin SCHILZ -
Aurélien -
Florian Coulmier -
Francois Romieu -
Greg -
Jean Weisbuch -
jean-yves＠lenhof.eu.org -
Marc Fournier -
Stéphane Diacquenod -
Sylvain Vallerot -
Wallace