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]

Message-ID: <20100616143659.GA14616@elliptictech.com>
Date:	Wed, 16 Jun 2010 10:36:59 -0400
From:	Nick Bowler <nbowler@...iptictech.com>
To:	Andy Whitcroft <apw@...onical.com>
Cc:	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 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.

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
-rc2.

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
--
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/