On Tue, 2013-02-12 at 09:12 +0100, Stanislav Meduna wrote: > On 12.02.2013 08:06, Mike Galbraith wrote: > > >> In this case pick_next_task takes idle tasks and idle wastes cpu > >> time. > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
