Si tu lisais le journal, tu éviterais de faire des commentaires "bateau", JACK est en espace utilisateur, ce qui a un surcoût en latence donc pour compenser il faut diminuer la taille des buffers d'où une utilisation de CPU importante.
Quand à toi, tu devrais questionner ce que tu lit ;-) Augmenter la taille des buffers mange de la RAM, pas du CPU. Ou alors il y a une astuce mais c'est pas trivial et certainement pas juste écrit dans le journal.
Sinon, fondamentalement, ça semble être un problème d’ordonnanceur plus que noyau versus utilisateur (j'ai pas de chiffres mais franchement quelques changements de contexte ça semble super bon marché comparé à être préempté au mauvais moment). Et pour paraphraser l'auteur de Jack, ça fait longtemps qu'on fait plus le boulot dans les bottom halves des gestionaires d’interruptions. Je comprendrais que le gars défende un ou deux syscalls supplémentaire pour ordonner des trucs spécifique au scheduler (encore qu'à mon avis y'a déjà ce qu'il faut) mais là… j'ai du mal à interpréter son choix de conception autrement que comme une envie de garder l'API OSS en y rajoutant les fonctions modernes.
Mais je suis peut être mauvaise langue. On verra bien où ça nous mène.
[^] # Re: Jack et le temps réel
Posté par un_brice (site web personnel) . En réponse à la dépêche KLANG - Kernel Level Audio Next Generation. Évalué à -6.
Quand à toi, tu devrais questionner ce que tu lit ;-) Augmenter la taille des buffers mange de la RAM, pas du CPU. Ou alors il y a une astuce mais c'est pas trivial et certainement pas juste écrit dans le journal.
Sinon, fondamentalement, ça semble être un problème d’ordonnanceur plus que noyau versus utilisateur (j'ai pas de chiffres mais franchement quelques changements de contexte ça semble super bon marché comparé à être préempté au mauvais moment). Et pour paraphraser l'auteur de Jack, ça fait longtemps qu'on fait plus le boulot dans les bottom halves des gestionaires d’interruptions. Je comprendrais que le gars défende un ou deux syscalls supplémentaire pour ordonner des trucs spécifique au scheduler (encore qu'à mon avis y'a déjà ce qu'il faut) mais là… j'ai du mal à interpréter son choix de conception autrement que comme une envie de garder l'API OSS en y rajoutant les fonctions modernes.
Mais je suis peut être mauvaise langue. On verra bien où ça nous mène.