Hello,
recently I debugged a problem on an -rt enabled kernel. The relevant
part of the analysed trace looks as follows:
napi/can0-10-360 [001] d...312 3565.642595: sched_pi_setprio: comm=candump pid=2182 oldprio=120 newprio=14
napi/can0-10-360 [001] d...212 3565.642619: sched_switch: prev_comm=napi/can0-10 prev_pid=360 prev_prio=14 prev_state=R ==> next_comm=cantest next_pid=915 next_prio=39
....
rcuc/0-15 [000] d...212 3565.642633: sched_switch: prev_comm=rcuc/0 prev_pid=15 prev_prio=98 prev_state=R+ ==> next_comm=candump next_pid=2182 next_prio=14
candump-2182 [000] d...3.. 3565.642646: sched_pi_setprio: comm=candump pid=2182 oldprio=14 newprio=120
So the napi/can0-10 wants to grab a mutex that candump is holding. So
candump's priority is bumped from 120 to 14.
However the napi/can0-10 process (and a few others) are pinned to cpu #1
and cantest isn't allowed to run on that one. And so cpu #1 schedules a
lower prio task while candump still has to wait a moment before being
scheduled on cpu #0.
I wonder if it would be sensible in such a case not only to increase the
importance of candump, but also to allow it to run on the cpu-set the
boosting process is allowed to run on until it releases the mutex.
Would that make sense?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
