Y a des nouvelles features (ASID / PCID) dans les proc les plus récents qui permettent de flusher sélectivement ou un truc du style, et donc mitiger les pertes de perfs, mais même avec ces features elles restent notables, et en plus surtout dans les régimes où elles sont déjà grandes à la bases.
Personnellement je viens de mesurer un passage de certains syscalls que j'ai patché ya pas longtemps (semget & co) de 200ns (Linux 4.14.10) à 400ns (Linux 4.14.11) (avec un microbenchmark pas extrêmement représentatif de vrai workloads - sauf peut-être dans des softs au design bizarre - c'est plus par curiosité). Vu la technique utilisée c'est pas juste xN ou +200ns, mais une loi complexe qui démarre avec un surcoût de durée constante au départ, puis un facteur multiplicatif très grand pour les premiers accès mémoires, et qui est progressivement amorti au fur et à mesure que les caches se rechargent. Un microbenchmark à base de getpid() montre un ralentissement d'un facteur 4 sur celui là (mais bon, là vraiment personne ne fait ça, c'est juste pour avoir une idée des cas les plus extrêmes).
Bref certains softs activement maintenus vont se mettre à jouer à un nouveau jeux; éviter les syscalls. Par exemple si l'émission d'une simple trace flush trop de caches userspace, ça va être un peu gênant.
[^] # Re: Concrètement ?
Posté par Guillaume Knispel . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à 7.
Y a des nouvelles features (ASID / PCID) dans les proc les plus récents qui permettent de flusher sélectivement ou un truc du style, et donc mitiger les pertes de perfs, mais même avec ces features elles restent notables, et en plus surtout dans les régimes où elles sont déjà grandes à la bases.
Personnellement je viens de mesurer un passage de certains syscalls que j'ai patché ya pas longtemps (semget & co) de 200ns (Linux 4.14.10) à 400ns (Linux 4.14.11) (avec un microbenchmark pas extrêmement représentatif de vrai workloads - sauf peut-être dans des softs au design bizarre - c'est plus par curiosité). Vu la technique utilisée c'est pas juste xN ou +200ns, mais une loi complexe qui démarre avec un surcoût de durée constante au départ, puis un facteur multiplicatif très grand pour les premiers accès mémoires, et qui est progressivement amorti au fur et à mesure que les caches se rechargent. Un microbenchmark à base de getpid() montre un ralentissement d'un facteur 4 sur celui là (mais bon, là vraiment personne ne fait ça, c'est juste pour avoir une idée des cas les plus extrêmes).
Bref certains softs activement maintenus vont se mettre à jouer à un nouveau jeux; éviter les syscalls. Par exemple si l'émission d'une simple trace flush trop de caches userspace, ça va être un peu gênant.