linux-kernel - Re: Why is kslowd accumulating so much CPU time?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 16 Jun 2010 15:55:30 +0100
From:	Andy Whitcroft <apw@...onical.com>
To:	Andy Whitcroft <apw@...onical.com>,
	David Howells <dhowells@...hat.com>, tytso@....edu,
	Dave Airlie <airlied@...il.com>,
	Dave Airlie <airlied@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: Why is kslowd accumulating so much CPU time?

On Wed, Jun 16, 2010 at 3:36 PM, Nick Bowler <nbowler@...iptictech.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/