Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Czasami odtwarzanie dźwięku w głośnikach potrafi się przyciąć na chwilę. Zwykle dzieje się to w momencie dość mocnego obciążenia maszyny. Do tej pory korzystałem z rtkit ale pewne aplikacje zwykłego użytkownika nadużywały ten mechanizm. Postanowiłem wywalić rtkit i zastąpić go przez włączenie opcji CONFIG_RT_GROUP_SCHED w kernelu. Ta opcja oczywiście wymaga skonfigurowanego cgroups i to akurat nie problem ale ile dokładnie %CPU wymaga dźwięk odtwarzany na kompie? xD
Z dokumentacji kernela można wyczytać, że po włączeniu CONFIG_RT_GROUP_SCHED, w strukturze cgroups pojawią się pliki cpu.rt_period_us oraz cpu.rt_runtime_us. No to dodałem sobie grupę dla procesu pulseaudio, bo to on się tutaj dźwiękiem zajmuje i pytanie jest jakie wartości do tych dwóch plików powinny powędrować?
Tam w dokumentacji był taki przykład:
Now if the audio thread needs to refill the DMA buffer every 0.005s, but
needs only about 3% CPU time to do so, it can do with a 0.03 * 0.005s =
0.00015s. So this group can be scheduled with a period of 0.005s and a run time
of 0.00015s.
No i jak to oszacować?
Jedyne co mi przyszło do głowy to:
# pidstat -h -r -u -v -p $(pidof pulseaudio) 1 .. # Time UID PID %usr %system %guest %wait %CPU CPU minflt/s majflt/s VSZ RSS %MEM threads fd-nr Command 10:38:11 1000 3800 0.00 1.00 0.00 0.00 1.00 0 0.00 0.00 1574656 28508 0.36 5 52 pulseaudio # Time UID PID %usr %system %guest %wait %CPU CPU minflt/s majflt/s VSZ RSS %MEM threads fd-nr Command 10:38:12 1000 3800 1.00 0.00 0.00 0.00 1.00 1 0.00 0.00 1574656 28508 0.36 5 52 pulseaudio # Time UID PID %usr %system %guest %wait %CPU CPU minflt/s majflt/s VSZ RSS %MEM threads fd-nr Command 10:38:13 1000 3800 1.00 1.00 0.00 0.00 2.00 0 2.00 2.00 1836800 28508 0.36 5 55 pulseaudio # Time UID PID %usr %system %guest %wait %CPU CPU minflt/s majflt/s VSZ RSS %MEM threads fd-nr Command 10:38:14 1000 3800 2.00 1.00 0.00 0.00 3.00 3 1.00 0.00 1574656 28456 0.36 5 52 pulseaudio ...
No i tu wychodzi, że w sumie %CPU dla pulseaudio jest tak koło 5% jednego rdzenia w szczycie. Czyli cpu.rt_period_us by był 0.05? A co z tym cpu.rt_runtime_us ? Jak go wyliczyć, bo raczej ten bufor DMA się nie napełnia na każdej maszynie w tym samym interwale 0.005s? xD
Offline
Do dźwięku u mnie starcza to, co ma konkretny proces w cgroup.
U Ciebie nie ma problemu z przydziałem do dźwięku, ino z przydziałem do PA.
Ustaw, że nic w systemie nie może zająć 90% proca, i powinno być ok.
Osobiście np ustawiłem emerge domyślnie na rdzenie 1-3 i 24k/10k,
# root ~> grep emerge `which cgstart` | egrep '_us|cpuset.cpus' echo '24000' > $CGDIR/cpu/system/emerge/cpu.cfs_quota_us echo '10000' > $CGDIR/cpu/system/emerge/cpu.cfs_period_us echo -n '1-3' > $CGDIR/cpuset/system/emerge/cpuset.cpus
z możliwością zwiększenia na rdzenie 0-3 i 32k/10k:
echo '32000' > /cgroup/cpu/system/emerge/cpu.cfs_quota_us echo -n '0-3' >/cgroup/cpuset/system/emerge/cpuset.cpus
Czyli bez względu na wszystko, może na 3 albo 4 rdzeniach zająć maksymalnie 80% zajętych rdzeni.
Do tego:
echo '900' > $CGDIR/cpu/system/emerge/cpu.shares
I nawet przy kompilacji qtwebengine nic się nie zacina.
Jeżeli pozwolisz jakimś procesom zając 100% proca, to nawet przy super priorytetach cgroup będą potrzebowały czasu żeby się posunąć dla np PA i będę zajmowały błyskawicznie wolne miejsce, a posuwały się przed PA z opóźnieniem.
Dlatego masz lagi w głośnikach.
Musisz zostawić kawałek proca wolny, żeby programy RT miały gdzie pracować bez oczekiwania na zwolnienie zajętych zasobów, bo przez to oczekiwanie całe RT diabli biorą.
To by było na tyle
Ostatnio edytowany przez Jacekalex (2021-11-28 23:41:03)
Offline
No generalnie to 0.95s na każdą 1s jest przydział procka pod zadania RT. Pozostałe zadania dostają 0.05s ale to tylko na wypadek gdyby zadania RT chciały zjadać cały procek, bo wtedy te inne zadania by zostały zdławione i nie dostały by w ogóle dostępu do procesora.
Te zadania RT mają tę przewagę nad zwykłymi, że są wykonywane zawsze jako pierwsze na procku nie ważne co tam by było zakolejkowane wcześniej. Różnicę można zobaczyć np. odpalając w terminalu takie polecenie:
# stress-ng --cpu 64 --io 4 --vm 2 --vm-bytes 8000M
A w innym terminalu odpalając np. htop i przy pomocy strzałek przemieszczać się po procesach.
Jak się nie oddeleguje jakiejś części CPU pod RT dla procesu htop, to wtedy można zaobserwować dość mocny lag przy przechodzeniu do innych pozycji przy pomocy strzałek. Ale jak tylko się ustawi w cgroups dla htop jakiś przydział RT, to od razu htop zaczyna działać płynnie.
Dlatego właśnie wolałbym przydzielić czas RT procka dla dźwięku, bo wtedy nic nie ma prawa się przyciąć. Póki co mam tylko jeden proces (pulseaudio), który miałby działać jako zadanie RT i cokolwiek przypiszę w cgroups to będzie działać ale przydałoby się zdobyć umiejętność określania tych czasów zawczasu. xD
Offline