From: Dave Airlie <airlied@gmail.com>
To: tytso@mit.edu, Dave Airlie <airlied@gmail.com>,
Dave Airlie <airlied@redhat.com>,
David Howells <dhowells@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: Why is kslowd accumulating so much CPU time?
Date: Mon, 14 Jun 2010 06:00:49 +1000 [thread overview]
Message-ID: <AANLkTilQLk7ofSJBm9KIa2g1KQ35GC1D1vOZlPrv1VRv@mail.gmail.com> (raw)
In-Reply-To: <20100613194949.GC8055@thunk.org>
On Mon, Jun 14, 2010 at 5:49 AM, <tytso@mit.edu> wrote:
> On Sun, Jun 13, 2010 at 06:23:45PM +1000, Dave Airlie wrote:
>>
>> Its an output polling feature of KMS, however it shouldn't cause
>> disruption elsewhere, but we are holding a mutex in there that there
>> isn't a real need to hold, so I suspect I'll drop that.
>
>> What GPU is it?
>
> It's a Lenovo T400, with an Intel GPU:
>
> (--) PCI:*(0:0:2:0) 8086:2a42:17aa:20e4 Intel Corporation Mobile 4 Series Chipse
> t Integrated Graphics Controller rev 7, Mem @ 0xf4400000/4194304, 0xd0000000/268
> 435456, I/O @ 0x00001800/8
>
> Why does KMS need to poll so frequently? 40 minutes of CPU time
> accumulated in 4 hours of uptime translates to 16% of the CPU being
> consumed by kslowd daemons, which seems... excessive.
>
> I've seen upgraded the userspace to Ubuntu Lucid (from Karmic) and the
> kernel to a post 2.6.35-rc2 (without the vt memory corruptor), and
> after 4 days, 5 hours of uptime, and I'm seeing something better:
>
> root 6390 4.7 0.0 0 0 ? S< Jun12 49:12 [kslowd001]
> root 6784 2.4 0.0 0 0 ? S< Jun09 150:50 [kslowd003]
> root 20047 2.7 0.0 0 0 ? S< Jun10 122:38 [kslowd002]
> root 32324 4.6 0.0 0 0 ? S< Jun12 49:54 [kslowd000]
>
> So that's 372 minutes of CPU time accumulated by kslowd in 6060
> minutes, or about 6% of the CPU --- but part of tha time the laptop
> was suspended --- and it still seems high.
>
> I have the following patch which I'm going to install later tonight to
> see if I can figure out if it really is drm_crtc_helper.c which is
> really responsible for all of the kslowd time being burned, but an
> examination of the source doesn't seem to show any other that I'm
> using that would likely be using the slow workqueue.
It most likely is, but polling shouldn't really be taking huge amounts
of CPU, unless there are some u/mdelays in there which would be bad.
In theory on Intel with hotplug irqs we shouldn't be poilling at all,
I must check why, the other thing is you could be suffering from the
hotplug irq problem that others have reported, this would cause slow
work triggers which aren't part of the normal poll cycle.
Dave.
next prev parent reply other threads:[~2010-06-13 20:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-09 18:36 Why is kslowd accumulating so much CPU time? Theodore Ts'o
2010-06-09 18:56 ` David Howells
2010-06-09 19:00 ` David Howells
2010-06-13 8:23 ` Dave Airlie
2010-06-13 19:49 ` tytso
2010-06-13 20:00 ` Dave Airlie [this message]
2010-06-14 18:42 ` Nick Bowler
2010-06-14 21:46 ` tytso
2010-06-15 17:25 ` Andy Whitcroft
2010-06-15 18:07 ` David Howells
2010-06-16 11:37 ` Andy Whitcroft
2010-06-16 13:33 ` Andy Whitcroft
2010-06-16 14:36 ` Nick Bowler
2010-06-16 14:55 ` Andy Whitcroft
2010-06-17 13:25 ` Nick Bowler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTilQLk7ofSJBm9KIa2g1KQ35GC1D1vOZlPrv1VRv@mail.gmail.com \
--to=airlied@gmail.com \
--cc=airlied@redhat.com \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).