La Fibre
Datacenter et équipements réseaux => Équipements réseaux => 
NAS, serveurs et micro-serveurs => Discussion démarrée par: vivien le 28 avril 2015 à 11:24:45
-
Aujourd'hui, une grande partie des processeurs d’Intel intègrent de Hyper-Threading. C'est le cas des core-i3 (PC fixes et portables) et des core-i5 (pour les portables uniquement) et des core-i7 (PC fixes et portables).
Schématiquement, l’hyper-threading consiste à créer deux processeurs logiques sur une seule puce, chacun doté de ses propres registres de données et de contrôle, et d’un contrôleur d’interruptions particulier. Ces deux unités partagent les éléments du cœur de processeur, le cache et le bus système. Ainsi, deux sous-processus peuvent être traités simultanèment par le même processeur. Cette technique multitâche permet d’utiliser au mieux les ressources du processeur en garantissant que des données lui sont envoyées en masse. Elle permet aussi d’améliorer les performances en cas de défauts de cache (cache misses). Source : Wikipedia (https://fr.wikipedia.org/wiki/Hyper-Threading)
J'ai un processeur Intel Core™ i3-2120 (http://ark.intel.com/fr/products/53426/Intel-Core-i3-2120-Processor-3M-Cache-3_30-GHz), équipé de 2 cœurs avec de l'Hyper-Threading et qui est donc vu par les différentes systèmes d’exploitation comme 4 CPU, ce qui est normal.
Ce qui m'étonne, c'est le répartition de charge quand j’utilise 2 CPU au maximum : Le système d’exploitation (Linux 3.19 ici avec Ubuntu 15.04) va faire tourner les 2 processus de temps en temps sur le même cœur physique si je comprend bien les courbes ci-dessous :
Au début, les CPU 1 et 2 sont utilisés, ensuite on passe au CPU 2 et 3, puis 1 et 2 de nouveau, CPU 1 et 4 ensuite, CPU 1 et 2, CPU 3 et 4,....
Bref, je ne sais pas si le cœur 1 correspond au CPU 1 et 2 et le coeur 2 au CPU 3 et 4, mais l'utilisaiton de 2 Threads d'un même cœur, tout en laissant le second cœur inutilisé est contre performant, non ?
(https://lafibre.info/testdebit/ubuntu/201504_ubuntu_utilisation_cpu_1.png)
Les caractéristiques de mon Core™ i3-2120 :
(https://lafibre.info/testdebit/ubuntu/201504_ubuntu_utilisation_cpu_2.png)
-
question que je me suis posé également...
honnêtement le fonctionnement de l'hyperthreading est flou.
est ce que utilisés simultanèment les 2 coeurs logiques ont la même perf ou 1 sera plus perf que l'autre?
en cas d'usage qui n'est pas multi thread est ce qu'il ne vaut pas mieux désactiver le mécanisme?
bref pleins de questions ;)
-
L'hyper threading est je crois gérer par l' OS. Donc à part les jeux je crois qu'il gère vraiment au mieux!!
-
Dans ce cas de figure d'alternance entre les différents cores/threads, les changements de contexte doit être vraiment contre productif si on compare à 2 CPU pleinement utilisé tout le long (cas d'Hyper Threading désactivé).
-
2 process en HT seront moins rapides que 2 process sur 2 coeurs différents. Dans le cas 1 Intel avance 20 à 30% de gain. Dans le cas 2 on peut espérer x2.
Sous Linux, il faut regarder /proc/cpuinfo pour l'affectation des id.
-
2 process en HT seront moins rapides que 2 process sur 2 coeurs différents. Dans le cas 1 Intel avance 20 à 30% de gain. Dans le cas 2 on peut espérer x2.
Sous Linux, il faut regarder /proc/cpuinfo pour l'affectation des id.
Bien sur car les threads sont découpés et/ou alterné sur un même core physique!
-
J'ai oublié de dire que le HT est désactivé sur mon i7 de bureau (effets de bord bizarres sur ma carte gfx Nvidia et VirtualBox) mais qu'il est actif sur mon portable en i3 et mon pro en i5.
-
Sous Linux, il faut regarder /proc/cpuinfo pour l'affectation des id.
C'est intéressant !
CPU 1 (processor 0) => core id 0
CPU 2 (processor 1) => core id 1
CPU 3 (processor 2) => core id 0
CPU 4 (processor 3) => core id 1
Il faut donc privilégier le fonctionnement du CPU 1 avec le CPU 2 ou CPU4 quand on a seulement 2 threads (et éviter les combinaisons CPU 1 + CPU 3 / CPU 2 + CPU 4).
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
stepping : 7
microcode : 0x28
cpu MHz : 1842.199
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx lahf_lm arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs :
bogomips : 6587.30
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
stepping : 7
microcode : 0x28
cpu MHz : 1783.675
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx lahf_lm arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs :
bogomips : 6587.30
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
stepping : 7
microcode : 0x28
cpu MHz : 2048.191
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx lahf_lm arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs :
bogomips : 6587.30
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
stepping : 7
microcode : 0x28
cpu MHz : 1936.042
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx lahf_lm arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs :
bogomips : 6587.30
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
-
il y a moyen de le paramétrer ça?
-
un article trouvé sur internet...
It splits a real CPU (a core) into 2. One is the real core, called the physical core. The other is just a secondary core, called the logical core. This logical core can't do much, but it does provide a little increased parallism. It is far from being a real core. In fact, it offers 10-20% (est., likely less) the performance of a real physical core. That's right, barely any computing power. Its purpose was simply to increase parallelism in a world dominated by I/O bound (non-CPU intensive) processes (actually threads, but we won't split hairs here). When a CPU intensive (CPU bound) thread is switched to one of these cores, its performance will substantially degrade
https://bitsum.com/pl_when_hyperthreading_hurts.php
-
enfaite après quelques recherches l'article précédent est complètement naz!
un article d'IBM sur le sujet:
http://www.ibm.com/developerworks/library/l-htl/
basé sur les noyaux linux 2.4 et 2.5 (ça date)
Linux kernel 2.4.x was made aware of HT since the release of 2.4.17. The kernel 2.4.17 knows about the logical processor, and it treats a Hyper-Threaded processor as two physical processors. However, the scheduler used in the stock kernel 2.4.x is still considered naive for not being able to distinguish the resource contention problem between two logical processors versus two separate physical processors.
Consider a system with two physical CPUs, each of which provides two virtual processors. If there are two tasks running, the current scheduler would let them both run on a single physical processor, even though far better performance would result from migrating one process to the other physical CPU. The scheduler also doesn't understand that migrating a process from one virtual processor to its sibling (a logical CPU on the same physical CPU) is cheaper (due to cache loading) than migrating it across physical processors.
The 2.5 scheduler maintains one run queue per processor and attempts to avoid moving tasks between queues. The change is to have one run queue per physical processor that is able to feed tasks into all of the virtual processors.
-
J'ai regardé pour le CPU du serveur LaFibre.info, un Intel Xeon CPU E31230 @ 3.20GHz, les cœurs HT ne sont pas à la fin, comme avec mon i3, mais ils suivent les cœurs physique :
$ cat /proc/cpuinfo
processor : 0
core id : 0
processor : 1
core id : 0
processor : 2
core id : 1
processor : 3
core id : 1
processor : 4
core id : 2
processor : 5
core id : 2
processor : 6
core id : 3
processor : 7
core id : 3
-
Je regarde tout à l'heure comment c'est géré sur le mien.
-
[root@localhost live]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 1559.250
cache size : 15360 KB
physical id : 0
siblings : 12
core id : 0
cpu cores : 6
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4215.81
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 1843.734
cache size : 15360 KB
physical id : 0
siblings : 12
core id : 1
cpu cores : 6
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4215.81
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 1966.453
cache size : 15360 KB
physical id : 0
siblings : 12
core id : 2
cpu cores : 6
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4215.81
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 1654.816
cache size : 15360 KB
physical id : 0
siblings : 12
core id : 3
cpu cores : 6
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4215.81
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 4
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 2217.550
cache size : 15360 KB
physical id : 0
siblings : 12
core id : 4
cpu cores : 6
apicid : 8
initial apicid : 8
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4215.81
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 5
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 1300.851
cache size : 15360 KB
physical id : 0
siblings : 12
core id : 5
cpu cores : 6
apicid : 10
initial apicid : 10
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4215.81
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 6
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 2399.906
cache size : 15360 KB
physical id : 1
siblings : 12
core id : 0
cpu cores : 6
apicid : 32
initial apicid : 32
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4220.40
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 2399.988
cache size : 15360 KB
physical id : 1
siblings : 12
core id : 1
cpu cores : 6
apicid : 34
initial apicid : 34
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4220.40
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 8
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 1474.921
cache size : 15360 KB
physical id : 1
siblings : 12
core id : 2
cpu cores : 6
apicid : 36
initial apicid : 36
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4220.40
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 9
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 1644.972
cache size : 15360 KB
physical id : 1
siblings : 12
core id : 3
cpu cores : 6
apicid : 38
initial apicid : 38
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4220.40
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 10
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 2399.988
cache size : 15360 KB
physical id : 1
siblings : 12
core id : 4
cpu cores : 6
apicid : 40
initial apicid : 40
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4220.40
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 11
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 2407.617
cache size : 15360 KB
physical id : 1
siblings : 12
core id : 5
cpu cores : 6
apicid : 42
initial apicid : 42
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4220.40
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 12
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 2424.433
cache size : 15360 KB
physical id : 0
siblings : 12
core id : 0
cpu cores : 6
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4215.81
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
-
processor : 13
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 2044.136
cache size : 15360 KB
physical id : 0
siblings : 12
core id : 1
cpu cores : 6
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4215.81
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 14
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 2506.382
cache size : 15360 KB
physical id : 0
siblings : 12
core id : 2
cpu cores : 6
apicid : 5
initial apicid : 5
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4215.81
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 15
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 2400.316
cache size : 15360 KB
physical id : 0
siblings : 12
core id : 3
cpu cores : 6
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4215.81
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 16
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 2380.300
cache size : 15360 KB
physical id : 0
siblings : 12
core id : 4
cpu cores : 6
apicid : 9
initial apicid : 9
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4215.81
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 17
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 2452.406
cache size : 15360 KB
physical id : 0
siblings : 12
core id : 5
cpu cores : 6
apicid : 11
initial apicid : 11
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4215.81
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 18
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 1894.921
cache size : 15360 KB
physical id : 1
siblings : 12
core id : 0
cpu cores : 6
apicid : 33
initial apicid : 33
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4220.40
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 19
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 1854.726
cache size : 15360 KB
physical id : 1
siblings : 12
core id : 1
cpu cores : 6
apicid : 35
initial apicid : 35
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4220.40
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 20
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 1762.851
cache size : 15360 KB
physical id : 1
siblings : 12
core id : 2
cpu cores : 6
apicid : 37
initial apicid : 37
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4220.40
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 21
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 1613.062
cache size : 15360 KB
physical id : 1
siblings : 12
core id : 3
cpu cores : 6
apicid : 39
initial apicid : 39
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4220.40
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 22
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 2287.359
cache size : 15360 KB
physical id : 1
siblings : 12
core id : 4
cpu cores : 6
apicid : 41
initial apicid : 41
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4220.40
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 23
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x416
cpu MHz : 1929.292
cache size : 15360 KB
physical id : 1
siblings : 12
core id : 5
cpu cores : 6
apicid : 43
initial apicid : 43
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips : 4220.40
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
-
Voilà tout en vrac car pour moi c'est du chinois
-
C'est un serveur avec un bi processeur Intel® Xeon E5-2620 v2.
Chaque processeur à 6 cœurs et 12 threads.
L'organisation, c'est :
- en 1er les 6 cœurs physique du 1er CPU
- en second les 6 cœurs logiques du 1er CPU
- en 3ème, les 6 cœurs physique du 2ème CPU
- en 4ème, les 6 cœurs logiques du 2ème CPU
-
Ok c'est plus clair comme ça, mais j'aurai vu la ligne 2 & 3 inversé. Ca me semble plus logique de répartir la charge sur les deux CPU de façon physique.
Là il n'y en a qu'un qui bosse en général.
-
Les "cœurs" partagent quoi exactement?
-
tu parle des coeur logiques ou physiques?
-
Cœurs qui existent réellement.
cœurs logiques = cœurs virtuels = cœurs bidons
-
de ce que j'en sais juste le cache de
niveau 2?
edit plutot le L3 le L2 est pour chaque coeur
après ya le controleur mémoire et autre mais c'est pas vraiment le cpu
-
Sous Linux:
Each CPU has a "base" scheduling domain (struct sched_domain). The domain
hierarchy is built from these base domains via the ->parent pointer. ->parent
MUST be NULL terminated, and domain structures should be per-CPU as they are
locklessly updated.
Each scheduling domain spans a number of CPUs (stored in the ->span field).
A domain's span MUST be a superset of it child's span (this restriction could
be relaxed if the need arises), and a base domain for CPU i MUST span at least
i. The top domain for each CPU will generally span all CPUs in the system
although strictly it doesn't have to, but this could lead to a case where some
CPUs will never be given tasks to run unless the CPUs allowed mask is
explicitly set. A sched domain's span means "balance process load among these
CPUs".
Each scheduling domain must have one or more CPU groups (struct sched_group)
which are organised as a circular one way linked list from the ->groups
pointer. The union of cpumasks of these groups MUST be the same as the
domain's span. The intersection of cpumasks from any two of these groups
MUST be the empty set. The group pointed to by the ->groups pointer MUST
contain the CPU to which the domain belongs. Groups may be shared among
CPUs as they contain read only data after they have been set up.
Balancing within a sched domain occurs between groups. That is, each group
is treated as one entity. The load of a group is defined as the sum of the
load of each of its member CPUs, and only when the load of a group becomes
out of balance are tasks moved between groups.
In kernel/sched/core.c, trigger_load_balance() is run periodically on each CPU
through scheduler_tick(). It raises a softirq after the next regularly scheduled
rebalancing event for the current runqueue has arrived. The actual load
balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run
in softirq context (SCHED_SOFTIRQ).
The latter function takes two arguments: the current CPU and whether it was idle
at the time the scheduler_tick() happened and iterates over all sched domains
our CPU is on, starting from its base domain and going up the ->parent chain.
While doing that, it checks to see if the current domain has exhausted its
rebalance interval. If so, it runs load_balance() on that domain. It then checks
the parent sched_domain (if it exists), and the parent of the parent and so
forth.
Initially, load_balance() finds the busiest group in the current sched domain.
If it succeeds, it looks for the busiest runqueue of all the CPUs' runqueues in
that group. If it manages to find such a runqueue, it locks both our initial
CPU's runqueue and the newly found busiest one and starts moving tasks from it
to our runqueue. The exact number of tasks amounts to an imbalance previously
computed while iterating over this sched domain's groups.
*** Implementing sched domains ***
The "base" domain will "span" the first level of the hierarchy. In the case
of SMT, you'll span all siblings of the physical CPU, with each group being
a single virtual CPU.
In SMP, the parent of the base domain will span all physical CPUs in the
node. Each group being a single physical CPU. Then with NUMA, the parent
of the SMP domain will span the entire machine, with each group having the
cpumask of a node. Or, you could do multi-level NUMA or Opteron, for example,
might have just one domain covering its one NUMA level.
The implementor should read comments in include/linux/sched.h:
struct sched_domain fields, SD_FLAG_*, SD_*_INIT to get an idea of
the specifics and what to tune.
Architectures may retain the regular override the default SD_*_INIT flags
while using the generic domain builder in kernel/sched/core.c if they wish to
retain the traditional SMT->SMP->NUMA topology (or some subset of that). This
can be done by #define'ing ARCH_HASH_SCHED_TUNE.
Alternatively, the architecture may completely override the generic domain
builder by #define'ing ARCH_HASH_SCHED_DOMAIN, and exporting your
arch_init_sched_domains function. This function will attach domains to all
CPUs using cpu_attach_domain.
The sched-domains debugging infrastructure can be enabled by enabling
CONFIG_SCHED_DEBUG. This enables an error checking parse of the sched domains
which should catch most possible errors (described above). It also prints out
the domain structure in a visual format.
Pour résumer, les CPU sont répartis dans des struct sched_domain.
Par défaut, sur les systèmes multi-sockets, chaque socket est dans un domaine séparé.
Sur les systèmes multi-threads (le cas de l'hyperthreading, donc), chaque groupe de core (le physique et le ou les virtuel(s) sont dans un domaine séparé.
Lorsqu'une tâche demande de la ressource, elle est alloué à un groupe (le plus vide, j'imagine).
Lorsqu'un groupe est "saturé", des tâches peuvent être exportés vers un autre groupe.
Cela signifie qu'un process reste toujours dans le même groupe (sauf saturation CPU) et profite donc grandement du cache.
Cela signifie également que deux process séparés font être alloués à deux cores physiques si possible.
-
Merci pour l'information
-
Sous Linux:
Pour résumer, les CPU sont répartis dans des struct sched_domain.
Par défaut, sur les systèmes multi-sockets, chaque socket est dans un domaine séparé.
Sur les systèmes multi-threads (le cas de l'hyperthreading, donc), chaque groupe de core (le physique et le ou les virtuel(s) sont dans un domaine séparé.
Lorsqu'une tâche demande de la ressource, elle est alloué à un groupe (le plus vide, j'imagine).
Lorsqu'un groupe est "saturé", des tâches peuvent être exportés vers un autre groupe.
Cela signifie qu'un process reste toujours dans le même groupe (sauf saturation CPU) et profite donc grandement du cache.
Cela signifie également que deux process séparés font être alloués à deux cores physiques si possible.
Ok merci pour l'explication, mais pourquoi aller jusqu'à saturation avant de changer de CPU ?
L'autre a le même cache ???
Dans toutes vos explications, j'ai l'impressions que un seul CPU bosse si la charge n'est pas sufisante.
Je me trompe ?
Pourtant je n'ai pas le sentiment que un travail plus l'autre aux vue des T°
-
De nombreux programmes (la majorité) ne peuvent exploiter qu'un seul processus (donc un seul core) : les opérations ne sont pas décomposées en différents taches pour être traitées en parallèle.
Seuls les programmes qui sont des gros consommateurs sont optimisés pour équilibrer le travail sur plusieurs processus.
Un exemple : Tu ouvres un gros fichier .csv avec Calc ou un capture Wireshark de plusieurs centaines de Mo : L'opération est longue mais utilise un seul processus => Un processeur bi-coeur ira plus vite qu'un processeur 8 cœurs car les fréquences des 2 cœurs sont plus élevées qu'un 8 cœurs.
Pour un serveur, c'est pareil : un client qui fait un téléchargement https va utiliser un seul cœur. Par contre un Xeon E5-1410 @2.80GHz va réussir à gérer 10 Gb/s de transfert https sur un seul cœur. Habituellement sur un serveur tu as plusieurs requêtes en parallèle donc là cela utilises bien les différents cœur de ton PC.
Je comprend pourquoi Netflix arrive a gérer plus de 10 Gb/s de trafic par serveur alors le processeur est moyen de gamme (Intel® Xeon E3-1260L => 4 cœurs, 8 threads, 8M Cache, 2.40 GHz) et qu'il y a seulement 32Go de ram. Les E/S doivent être impressionnantes, mais sont gérées par 36 disques de 3 To SAS. Si le serveur sait gérer 18 Gb/s, cela fait en fait 500 Mb/s par disque, c'est possible.
-
Ok merci pour l'explication, mais pourquoi aller jusqu'à saturation avant de changer de CPU ?
L'autre a le même cache ???
Dans toutes vos explications, j'ai l'impressions que un seul CPU bosse si la charge n'est pas sufisante.
Je me trompe ?
Pourtant je n'ai pas le sentiment que un travail plus l'autre aux vue des T°
L'explication qu'on t'a donné s'applique à Linux, pas à Windows :)
Sous Windows, une tache est équilibrée sur tous les CPU (physiques ou virtuels) à tour de role : lance une tache mono-thread et ouvre le gestionnaire de taches. Normalement tu devrais voir tous les core avec une meme charge. En principe, la charge est divisée par le nombre de coeurs, donc si 2 cores = 50% chacun, 4 cores=25% chacun, etc.
Pour changer ce comportement et assigner une tache à un seul coeur pour améliorer le fonctionnement, il faut règler l'affinité : dans le gestionnaire de taches, clic-droit sur la tache et faire définir l'affinité. Une fenetre s'ouvre et il faut cocher un seul CPU dans la liste.
Cette gestion pénalise le fonctionnement des traitements mono-thread sous Windows à cause de la moindre efficacité du cache de chaque coeur. Il me semble que cela avait été amélioré à partir de Windows 7. Les versions Server ont le meme "défaut" mais sur un Server on a en principe bien plus qu'une tache à traiter !
-
Je ne comprends pas...
-
C'est pas contre productif de faire tourner une tâche de core en core très rapidement ?
C'est vrai que que sous windows j'ai été étonné mais j'ai déjà observé qu'un logiciel qui consomme beaucoup de CPU va charger les différents core à 25% (4 cœurs) ou 50% (bi-cœurs)
-
@corrector c'est quoi que tu comprends pas ? Mon explication ou la logique de Microsoft ?
@vivien en effet la tache sera moins efficace. J'ai du SMP depuis 2002 et c'est un problème connu de Windows. Pire il me semble que sous 2000/XP il pouvait commuter 2 taches parallèles d'un CPU à l'autre. D'où des outils comme SMP seesaw pour régler les affinités des tâches.
-
De nombreux programmes (la majorité) ne peuvent exploiter qu'un seul fil d'exécution (donc un seul core) : les opérations ne sont pas décomposées en différents taches pour être traitées en parallèle.
Petite correction sémantique : un processus peut être constitué de plusieurs fils d'exécution (threads).
À moins qu'ils n'aient rien à se dire du tout en interne ou que l'exécution doive se faire de façon distribuée sur plusieurs machines, il est plus efficace pour un programme d'utiliser un seul processus constitué de deux fils d'exécution (qui vont partager la même mémoire), que deux processus constitués d'un seul fil (qui devront faire appel aux mécanismes de communication inter-processus pour s'échanger des informations).
-
L'explication qu'on t'a donné s'applique à Linux, pas à Windows :)
Sous Windows, une tache est équilibrée sur tous les CPU (physiques ou virtuels) à tour de role : lance une tache mono-thread et ouvre le gestionnaire de taches. Normalement tu devrais voir tous les core avec une meme charge. En principe, la charge est divisée par le nombre de coeurs, donc si 2 cores = 50% chacun, 4 cores=25% chacun, etc.
Comment une seule tache est divisée en plusieurs?
C'est comme l'homéopathie, tu arrives à diluer une seule molécule?
-
Petite correction sémantique : un processus peut être constitué de plusieurs fils d'exécution (threads).
À moins qu'ils n'aient rien à se dire du tout en interne ou que l'exécution doive se faire de façon distribuée sur plusieurs machines,
Si tes threads sont très interdépendants, ça n'a peut être aucun intérêt de les paralléliser!
Sur une machine multi unités d'exécution (CPU ou "core"), tu as en général de nombreuses tâches en cours ou en attente d'exécution. Terminer plus vite une seule de ces tâche n'est pas forcèment utile.
il est plus efficace pour un programme d'utiliser un seul processus constitué de deux fils d'exécution (qui vont partager la même mémoire), que deux processus constitués d'un seul fil (qui devront faire appel aux mécanismes de communication inter-processus pour s'échanger des informations).
Les communications interprocessus ne sont pas forcèment moins efficaces que les communication intraprocessus. On peut utiliser exactement les mêmes outils : sémaphores, mutex, etc.
-
Un exemple : Tu ouvres un gros fichier .csv avec Calc ou un capture Wireshark de plusieurs centaines de Mo : L'opération est longue mais utilise un seul processus => Un processeur bi-coeur ira plus vite qu'un processeur 8 cœurs car les fréquences des 2 cœurs sont plus élevées qu'un 8 cœurs.
La lecture d'un fichier est une opération linéaire.
Pour un serveur, c'est pareil : un client qui fait un téléchargement https va utiliser un seul cœur. Par contre un Xeon E5-1410 @2.80GHz va réussir a gérer 10 Gb/s de transfert https sur un seul cœur.
Gérer une connexion HTTPS (coté client ou serveur) est typiquement le genre de chose qui n'admet aucun parallélisme.
Par contre coté client le rendu d'une page Web n'a pas besoin d'être fait dans un seul processus : chaque image existe indépendamment, et peut être décodée par un thread différent.
-
Comment une seule tache est divisée en plusieurs?
Je crois que tu as mal compris.
Si tu as une charge de 1 CPU, et que tu disposes de 4 CPU, tu peux tout à faire répartir cette charge de 1 sur les 4.
Le scheduleur tic à relativement haute fréquence : bien que d'un point de vu technique, la charge n'existe que sur un CPU à la fois, d'un point de vu relatif, tu la vois "un peu sur chaque".
Tu sais, c'est comme les effets visuelles (blur etc) : tu as l'impression de voir plusieurs fois la même chose, alors qu'elle n'existe, pour chaque instant T, qu'à un seul endroit.
La lecture d'un fichier est une opération linéaire.
Oui et non
Au niveau IO, la lecture d'un fichier peut être en fait la lecture de plusieurs morceaux de fichier (le regroupement de tout ces morceaux faisant le fichier en lui même). Et ces morceaux peuvent ne pas être linéairement placés (au niveau logique, je ne parle pas du niveau physique évidement).
Si je prends une base de données par exemple, je peux probablement faire un "select *" sur mon unique table, sans pour autant faire une lecture linéaire (depuis le début du fichier jusqu'à la fin).
-
Je crois que tu as mal compris.
Si tu as une charge de 1 CPU, et que tu disposes de 4 CPU, tu peux tout à faire répartir cette charge de 1 sur les 4.
Le scheduleur tic à relativement haute fréquence : bien que d'un point de vu technique, la charge n'existe que sur un CPU à la fois, d'un point de vu relatif, tu la vois "un peu sur chaque".
Ah je crois que j'ai compris, c'est pour pas user plus un CPU qu'un autre en fait.
Je fais pareil avec mes chaussettes (et pas mes sockets).
-
Si je prends une base de données par exemple, je peux probablement faire un "select *" sur mon unique table, sans pour autant faire une lecture linéaire (depuis le début du fichier jusqu'à la fin).
Si tu fais un select je pense qu'il va utiliser l'index et pas lire "linéairement" un fichier.
-
Il faudra bien que le moteur charge ses index à un moment ...
Si tes threads sont très interdépendants, ça n'a peut être aucun intérêt de les paralléliser!
Sur une machine multi unités d'exécution (CPU ou "core"), tu as en général de nombreuses tâches en cours ou en attente d'exécution. Terminer plus vite une seule de ces tâche n'est pas forcèment utile.
Et en général, le gars qui est devant sa machine apprécie toujours que son application continue d'être réactive, même si elle est occupée à faire autre chose.
Avant d'y chercher un gain en terme de performance, l'avantage de disposer de plusieurs fils d'exécution, c'est de pouvoir y coller des boucles de traitement (rafraîchissement de l'interface graphique, traitement des E/S, etc) qui sont justement relativement indépendantes les unes des autres.
Les communications interprocessus ne sont pas forcèment moins efficaces que les communication intraprocessus. On peut utiliser exactement les mêmes outils : sémaphores, mutex, etc.
Outre le fait qu'il n'est pas toujours indispensable de sortir l'artillerie lourde des IPC classiques pour faire communiquer deux fils entre eux (tant qu'ils ne risquent pas de se marcher sur les pieds, c'est parfaitement inutile), si l'ordonnanceur décide de faire tourner deux processus lourds communicant sur le même cœur, il y aura commutation de contexte, tandis que ce ne sera pas nécessaire si ce sont deux processus légers.
Donc pas forcèment moins efficaces, non, mais potentiellement moins efficaces, certainement.
-
Outre le fait qu'il n'est pas toujours indispensable de sortir l'artillerie lourde des IPC classiques pour faire communiquer deux fils entre eux (tant qu'ils ne risquent pas de se marcher sur les pieds, c'est parfaitement inutile), si l'ordonnanceur décide de faire tourner deux processus lourds communicant sur le même cœur, il y aura commutation de contexte, tandis que ce ne sera pas nécessaire si ce sont deux processus légers.
Donc pas forcèment moins efficaces, non, mais potentiellement moins efficaces, certainement.
Qu'appelles-tu les "processus légers"? Les threads?
-
Oui.