Ah oui, intéressant, je n'avais pas relevé cette valeur qui est effectivement assez haute. Si je ne m'abuse, la valeur par défaut du noyau est 128, read_wakeup_threshold étant lui à 64.
Par curiosité, c'est quelle distribution ? (Google semble me suggérer que ça pourrait être redhat, mais je n'en ai pas sous la main)
Aussi, je pense qu'il faut prendre en considération le delta entre read_wakeup_threshold et write_wakeup_threshold pour se faire une idée plus précise, puisque c'est la "zone" dans laquelle le kernel souhaite maintenir l'entropie (puisque seul un "gros" consommateur d'entropie va être en mesure de faire descendre en dessous de read_wakeup_threshold). Au vu du comportement que tu observes, je soupçonne que read_wakeup_threshold est configuré relativement haut aussi ?
Mais effectivement avec des niveaux aussi hauts, ça peut être un peu overkill d'aller taper le userland pour restaurer de l'entropie alors qu'on n'est pas forcément vraiment en manque. Aux valeurs de base que je mentionnais plus haut, ça se justifierait davantage peut-être.
En y réflechissant un peu plus, ça me semblerait d'ailleurs étrange de configurer des valeurs aussi hautes pour les seuils. J'ai l'impression que ça rendrait l'ensemble des consommateurs plus à la merci des pics d'un gros consommateur: dans un cas où on a N petits consommateurs et 1 gros, dès que le gros passe tous les petits vont devoir attendre que l'entropie remonte à un niveau très élevé. Au contraire quand les seuils sont plus bas, on va réveiller tout le monde régulièrement, et probablement en pratique ralentir le gros au bénéfice des petits.
Bon en même temps il semblerait que certains consommateurs ajustent leur consommation en fonction du niveau disponible, pour rendre les choses encore plus complexes...
Ça semble pas trivial à ajuster proprement au profil d'utilisation tout ça :)
[^] # Re: pilote noyau
Posté par Yann Hodique (site web personnel) . En réponse à la dépêche scdrand: alimenter le pool d’entropie du noyau à partir d’une carte à puce. Évalué à 2.
Ah oui, intéressant, je n'avais pas relevé cette valeur qui est effectivement assez haute. Si je ne m'abuse, la valeur par défaut du noyau est 128, read_wakeup_threshold étant lui à 64.
Par curiosité, c'est quelle distribution ? (Google semble me suggérer que ça pourrait être redhat, mais je n'en ai pas sous la main)
Aussi, je pense qu'il faut prendre en considération le delta entre read_wakeup_threshold et write_wakeup_threshold pour se faire une idée plus précise, puisque c'est la "zone" dans laquelle le kernel souhaite maintenir l'entropie (puisque seul un "gros" consommateur d'entropie va être en mesure de faire descendre en dessous de read_wakeup_threshold). Au vu du comportement que tu observes, je soupçonne que read_wakeup_threshold est configuré relativement haut aussi ?
Mais effectivement avec des niveaux aussi hauts, ça peut être un peu overkill d'aller taper le userland pour restaurer de l'entropie alors qu'on n'est pas forcément vraiment en manque. Aux valeurs de base que je mentionnais plus haut, ça se justifierait davantage peut-être.
En y réflechissant un peu plus, ça me semblerait d'ailleurs étrange de configurer des valeurs aussi hautes pour les seuils. J'ai l'impression que ça rendrait l'ensemble des consommateurs plus à la merci des pics d'un gros consommateur: dans un cas où on a N petits consommateurs et 1 gros, dès que le gros passe tous les petits vont devoir attendre que l'entropie remonte à un niveau très élevé. Au contraire quand les seuils sont plus bas, on va réveiller tout le monde régulièrement, et probablement en pratique ralentir le gros au bénéfice des petits.
Bon en même temps il semblerait que certains consommateurs ajustent leur consommation en fonction du niveau disponible, pour rendre les choses encore plus complexes...
Ça semble pas trivial à ajuster proprement au profil d'utilisation tout ça :)