Bug#944589: gsequencer: stalls system
It looks like I needed to do a reboot to verify the RT-bandwidth cap at
the 500000 limit for kernel.sched_rt_runtime_us in sysctl.. so "top"
shows gsequencer at 200% (when ags is set with 'jack')
500000 is about half rt period of 1 second(1000000), and so 200% on this
computer means it is half the cpu bandwidth on a 4-core machine I'm
using.. so this confirms the application is still saturating the RT
bandwidth.
500000/1000000 = 50%
200/400% = 50%
If you have a 2-core system, then saturation in the output of "top"
would be saying "100%" because the maximum cpu-bandwidth capacity is
200% for 2 cores.
By default, the cap-protection for RT-bandwidth is set at 950000.. I was
curious to see if sysctl's setting of kernel.sched_rt_runtime_us was
effective..
I've only known the basics, and I suppose there's something verifying
for me here as well, I'm pretty confident I've been learning about RT
things correctly as I've been setting up ardour+jack to work effectively..
maybe someone from debian team can help with the scheduling call things..
unfortunately I wouldn't be able to mentor coding specifics, but I know
it has something to do with schedule functions.
good luck..
Reply to: