On Tue, 2013-02-12 at 09:12 +0100, Stanislav Meduna wrote: 

On 12.02.2013 08:06, Mike Galbraith wrote:

quoted

quoted

In this case pick_next_task takes idle tasks and idle wastes cpu
time.

quoted

That's not a waste of CPU time, that's utilization enforcement the thing
it is designed to do.

Well this is a philosophical question and the opinions will IMHO
vary strongly. If the throttling kicks in, the system already
is in the out-of-spec state.

Exactly, please don't feed the wild eyed psychopaths ;-)

Is the goal now just to allow
e.g. the ssh login to be able to kill the task and still try
to do the best if otherwise (possibly masking the problem for
months), or is it to enforce the utilization?

Both.  It has two modes of enforcement, sane mode is I WILL constrain
this thing you turned loose should it acts up, and not so sane mode,
where borrowing a cup of CPU from the neighbors is ok.  Workqueues.

For example we have a PLC software where the end-user develops
an application that will be executed in our realtime task.
The application usually has a longer initialization part where
the excess utilization can happen and should be tolerated
and the running part where it is a bug if it happens. Here
I would prefer the throttling to alert the user, but not
to actually throttle if there is no non-RT task actually
wanting to run. In other cases I would maybe prefer even
killing the task, alerting the user to the fact.

That's not in the throttles job description.  It's not a monitor and
report system, it's a constraint system for very dangerous beasts.

I have a related question: is the information that the throttling
happened available somewhere except the log (where it gets only
written once)? If not, would a patch exporting the count
of throttlings via /sys be accepted?

I'm not the maintainer, so can't say.  Seems to me a trace point would
be better though.

-Mike