Messages in this thread | | | Date | Wed, 16 Jun 2010 15:55:30 +0100 | Subject | Re: Why is kslowd accumulating so much CPU time? | From | Andy Whitcroft <> |
| |
On Wed, Jun 16, 2010 at 3:36 PM, Nick Bowler <nbowler@elliptictech.com> wrote: > On 12:37 Wed 16 Jun , Andy Whitcroft wrote: >> > Can you see what they're doing? >> > >> > watch -n0 cat /sys/kernel/debug/slow_work/runqueue >> >> Turned on the debugging and applied the patch from Ted, and when >> things are bad I see constant cycling of all four threads in the >> output showing similar to the below, note only one thread shows at a >> time: >> >> Every 0.1s: cat /sys/kernel/debug/slow_work/runqueue Wed Jun 16 12:34:52 2010 >> >> THR PID ITEM ADDR FL MARK DESC >> === ===== ================ == ===== ========== >> 0 897 ffff88012bb07510 12 20ms DRM_CRTC_HELPER: i915@pci:0000:00:02.0 > > Indeed, this looks very similar to mine, except my DESC field is blank > for some reason. The FL value is sometimes 12, sometimes 2.
DESC is only filled in if you have Ted's patch applied (earlier in this thread).
> When things are bad, all four of the kslowd threads are pegged at 16% > CPU usage. On my T500, they _never_ calm down once they're pegged. > However, things seem to be working normally at boot. It seems that > there is some initial trigger which pegs the threads, then the cursor > lag and other problems are just fallout after that. The system is > essentially unusable after this point. > > The threads sometimes get pegged immediately after booting the system, > sometimes it can last an hour or more before showing any problems. > Unfortunately, this is making bisection essentially impossible. > > This seems to have been introduced somewhere between 2.6.35-rc1 and
I suspect this is introduced by the commit which pulled polling of DRM connectors into the core.
-apw -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |