Bug#944589: gsequencer: stalls system
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: