C'est déjà le cas, mais dorénavant l'impact d'un syscall a, selon le processeurs, des effets indirects élevés qui peuvent être très gênants sur certaines workload, et ça pourrait motiver à réorganiser du code pour éviter des syscalls appelés pas trop fréquemment qui en soit prennent peu de temps mais se mettent maintenant à flusher des caches.
Ainsi alors que certains soft n'auraient eu aucun intérêt à modifier leur code lorsque ce problème n'avait pas été découvert (ils n'en auraient tiré qu'une accélération marginale voire non mesurable), il est fort possible que dorénavant la chasse aux syscalls deviennent bien plus rentable. Ce qui est gênant c'est que du profiling par sampling de %rip pourrait ne pas indiquer parfaitement les endroits où viser, vu qu'une partie du ralentissement est indirect et dilué sur une "longue" période (quand on revient en userspace et que des trucs ont été flushés)
[^] # Re: Concrètement ?
Posté par Guillaume Knispel . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à 5.
C'est déjà le cas, mais dorénavant l'impact d'un syscall a, selon le processeurs, des effets indirects élevés qui peuvent être très gênants sur certaines workload, et ça pourrait motiver à réorganiser du code pour éviter des syscalls appelés pas trop fréquemment qui en soit prennent peu de temps mais se mettent maintenant à flusher des caches.
Ainsi alors que certains soft n'auraient eu aucun intérêt à modifier leur code lorsque ce problème n'avait pas été découvert (ils n'en auraient tiré qu'une accélération marginale voire non mesurable), il est fort possible que dorénavant la chasse aux syscalls deviennent bien plus rentable. Ce qui est gênant c'est que du profiling par sampling de %rip pourrait ne pas indiquer parfaitement les endroits où viser, vu qu'une partie du ralentissement est indirect et dilué sur une "longue" période (quand on revient en userspace et que des trucs ont été flushés)