Bug#944589: gsequencer: stalls system
The only thing I can do is to allow the user to configure AGS_RT_PRIORITY
http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/thread/ags_audio_loop.c?h=3.0.x&id=93bddce14d8b1bf98f30867babd9d36db1487fbf#n660
regards,
Joël
On Thu, Nov 28, 2019 at 6:21 AM westlake <westlake2012@videotron.ca> wrote:
>
> 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: