Hi Sebastian,
[..]
@@ -923,7 +924,11 @@ static int sched_rt_runtime_exceeded(str
*/
if (likely(rt_b->rt_runtime)) {
rt_rq->rt_throttled = 1;
- printk_deferred_once("sched: RT throttling activated\n");
+ printk_deferred("sched: RT throttling activated cmd %s "
+ "cpu %d pid %d prio %d us %llu flags 0x%08lx\n",
+ curr->comm, task_cpu(curr), task_pid_nr(curr),
+ MAX_RT_PRIO-1 - curr->prio, delta_exec >> 10,
+ (unsigned long) task_thread_info(curr)->flags);
I would keep the _once.
Ok.
Other than that, I don't think that the output is correct.
If you had said "The output may not always point to the culprit", I
immediately would agree. The probability of whether the real culprit is
hit or an innocent other RT task depends on their uninterrupted runtime.
Given that a legitimate RT task normally only runs for a couple of
microseconds and a task that causes RT throttling may run a thousand
times longer, the extended output still may provide a hint to solve the
problem. At least this is what I found when I did a number of
(admittedly artificial) experiments.
We could save a short history of RT tasks along with their uninterrupted
runtime and, in case of throttling, print the one with the longest
uninterrupted runtime.
Carsten.
--
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
