About documentation...
About documentation...
Posted Jul 25, 2007 20:46 UTC (Wed) by mingo (guest, #31122)In reply to: About documentation... by i3839
Parent article: Interview with Con Kolivas (APC)
So assuming that these values are in nanoseconds, ksoftirqd waited at most 111 ms before it could finally run, and X 81 ms.
Yes, the values are in nanoseconds. What priority does it have? [the prio field in /proc/[PID]/sched file] If it's niced to +19 then a longer delay is possible because other, high-prio tasks might delay it.
Posted Jul 25, 2007 22:03 UTC (Wed)
by i3839 (guest, #31386)
[Link] (3 responses)
Posted Jul 25, 2007 22:18 UTC (Wed)
by mingo (guest, #31122)
[Link] (2 responses)
Posted Jul 25, 2007 22:50 UTC (Wed)
by i3839 (guest, #31386)
[Link] (1 responses)
I suppose the best way to track any anomalies down is by applying latency-tracing-v2.6.23-rc1-combo.patch at your homepage? WAKEUP_TIMING seems slightly redundant now. I'll enable it anyway.
Posted Jul 25, 2007 23:41 UTC (Wed)
by i3839 (guest, #31386)
[Link]
ksoftirqd has prio 115 and X has prio 120. I didn't nice anything, so it's all default (all kernel threads at -5, user processes 0, except for pppd at -2 and udevd at -4).About documentation...
Ok. Perhaps the 100+ msecs ksoftirqd delay was during bootup. Or if you are running a !CONFIG_PREEMPT kernel such delays could happen too. But if you are running a CONFIG_PREEMPT kernel and ksoftirqd shows such large latencies even after resetting its counters, that would be an anomaly. (if so then please report it to me and/or to lkml in email.)
About documentation...
Ok, I'll keep an eye on it. Running PREEMPT here.About documentation...
I get compile errors with that patch, I'll send them by email.About documentation...