Bug#944589: gsequencer: stalls system
Hi,
Thank you very much for your information.
As you might have noticed there is much going on related to new threading API
in GSequencer v3.0.0
And thanks to your information you pointed me to allow adjusting
realtime priorities
by configuration seems to be mandatory.
https://savannah.nongnu.org/task/index.php?15477
best regards,
Joël
On Thu, Nov 28, 2019 at 5:51 AM westlake <westlake2012@videotron.ca> wrote:
>
> it will just spike back to 110% when there is even a small load because
> you're not addressing the scheduling issue.
>
> On a 4-core system, when 50% is reserved for the RT-bandwidth the
> greatest percentage for CPU% utilization becomes 200%.
>
> But it is 200% that is shared for all RT-policy tasks..
>
> basically this means 2 cores are fully saturated by that task in "cpu
> bandwidth"..
>
> it could be 2 cores each at 100% or 4 cores each having 50% utilization
> by the various threads by the application.
>
> A properly made application wouldn't saturate all available RT
> bandwidth, as that's called an out-of-control RT application...it's a
> scheduling-function coding issue...
>
> Any-time you have a run-away and in-appropriately scheduled application,
> you automatically have an improperly behaving application that can be
> used to do things it shouldn't..
>
> eg:: fork-bombing a webserver to saturate a server, ddos-attacks is
> doing what ags is doing in saturating the cpu so that no other security
> task can run..
>
> haven't coded in long time, but I'm experienced enough to understand the
> implications about process-bombing/saturation and run-away tasks..
>
> The "FIFO" you see in the pictures -- threads with this policy class are
> RT, and so is RR, as well as BATCH policy task.. so everything of these
> three all need to fit inside the same RT bandwidth.
>
> Ags incorrectly saturates the whole rt bandwidth leaving no RT
> bandwidth for any other RT task --- such as "drivers" which run on FIFO
> threads.
>
> I wouldn't be a strong mentor on programming at this point in time...
> but basically your application is running out of control when it is
> doing this -- and there's stability as well security issue related.
>
> My gut feeling here is you should be investigating scheduling functions
> as I think it's pretty obvious because there's an error message showing
> exactly this..
>
> Come back and update this report and let me know when this gets fixed.
> -- I could wait ..
>
> thanks
>
Reply to: