Prev: FRV: Implement the GDB remote protocol 'p' command to retrieve a register
Next: freeze when strace X
From: Dave Airlie on 13 Jun 2010 16:10
On Mon, Jun 14, 2010 at 5:49 AM, <tytso(a)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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Nick Bowler on 14 Jun 2010 14:50
On 06:00 Mon 14 Jun , Dave Airlie wrote:
> On Mon, Jun 14, 2010 at 5:49 AM, <tytso(a)mit.edu> wrote:
> > It's a Lenovo T400, with an Intel GPU:
> >
[...]
> > 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 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.

This sounds exactly like the issue I've been seeing on a T500 laptop, as
well (GM45 board). The slowdowns render the system essentially
unusable, as it can spend a loooong time just moving the mouse cursor a
few pixels on the screen. During this time, nothing else on the display
is updating (glxgears drops to 0fps). Things generally seem to be
working fine if I am not moving the mouse, or if I'm not running X.

I do not have this issue on a desktop machine with a G45.

Unfortunately, bisection is proving difficult because the exact set of
conditions to trigger the problems seem to be eluding me: sometimes the
kernel will work perfectly fine for quite some time, and then go
downhill from there. However, this is definitely a regression
introduced after 2.6.35-rc1.

--
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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: tytso on 14 Jun 2010 17:50
On Mon, Jun 14, 2010 at 02:42:44PM -0400, Nick Bowler wrote:
>
> This sounds exactly like the issue I've been seeing on a T500 laptop, as
> well (GM45 board). The slowdowns render the system essentially
> unusable, as it can spend a loooong time just moving the mouse cursor a
> few pixels on the screen. During this time, nothing else on the display
> is updating (glxgears drops to 0fps). Things generally seem to be
> working fine if I am not moving the mouse, or if I'm not running X.

I saw exactly the same behaviour when using the Ubuntu Karmic
userspace. Basically, using a 2.6.35-rc2 (+ vt memory corrupter fix)
kernel, the system was essentially unusable. Interestingly, the
problem went away (with the same kernel) once I updated to Ubuntu
Lucid. I was going to mention that so that hopefully someone with far
more X.org-fu than I could figure out how much of this is a X server
bug, and how much of this was a kernel bug, but things worked just
*fine* with 2.6.34 kernel.

Occasionally it will happen that the mouse stops tracking, and then I
grumble and curse, and a few seconds later it resolves itself. I
haven't had time to track it down; but the problem was breathtakingly
easy to reproduce with an Ubuntu Karmic userspace. :-)

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andy Whitcroft on 15 Jun 2010 13:30
On Mon, Jun 14, 2010 at 10:46 PM, <tytso(a)mit.edu> wrote:
> On Mon, Jun 14, 2010 at 02:42:44PM -0400, Nick Bowler wrote:
>>
>> This sounds exactly like the issue I've been seeing on a T500 laptop, as
>> well (GM45 board). �The slowdowns render the system essentially
>> unusable, as it can spend a loooong time just moving the mouse cursor a
>> few pixels on the screen. �During this time, nothing else on the display
>> is updating (glxgears drops to 0fps). �Things generally seem to be
>> working fine if I am not moving the mouse, or if I'm not running X.
>
> I saw exactly the same behaviour when using the Ubuntu Karmic
> userspace. �Basically, using a 2.6.35-rc2 (+ vt memory corrupter fix)
> kernel, the system was essentially unusable. �Interestingly, the
> problem went away (with the same kernel) once I updated to Ubuntu
> Lucid. �I was going to mention that so that hopefully someone with far
> more X.org-fu than I could figure out how much of this is a X server
> bug, and how much of this was a kernel bug, but things worked just
> *fine* with 2.6.34 kernel.
>
> Occasionally it will happen that the mouse stops tracking, and then I
> grumble and curse, and a few seconds later it resolves itself. �I
> haven't had time to track it down; but the problem was breathtakingly
> easy to reproduce with an Ubuntu Karmic userspace. �:-)

I am seeing crunchy cursor behavior on boot on Ubuntu Lucid user space
with the 2.6.35-rc3 kernel as well. It pretty much always does that
on boot, and often later as well. Right now I have four of these
chaps each consuming 9% of a CPU. Though they definatly come and go.
Very odd:

938 root 15 -5 0 0 0 S 9 0.0 1:00.90 kslowd001
1048 root 15 -5 0 0 0 S 9 0.0 1:01.12 kslowd002
937 root 15 -5 0 0 0 S 8 0.0 1:00.92 kslowd000
1544 root 15 -5 0 0 0 D 8 0.0 1:00.55 kslowd003

-apw
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Howells on 15 Jun 2010 14:10
Andy Whitcroft <apw(a)canonical.com> wrote:

> I am seeing crunchy cursor behavior on boot on Ubuntu Lucid user space
> with the 2.6.35-rc3 kernel as well. It pretty much always does that
> on boot, and often later as well. Right now I have four of these
> chaps each consuming 9% of a CPU. Though they definatly come and go.
> Very odd:
>
> 938 root 15 -5 0 0 0 S 9 0.0 1:00.90 kslowd001
> 1048 root 15 -5 0 0 0 S 9 0.0 1:01.12 kslowd002
> 937 root 15 -5 0 0 0 S 8 0.0 1:00.92 kslowd000
> 1544 root 15 -5 0 0 0 D 8 0.0 1:00.55 kslowd003

Can you see what they're doing?

watch -n0 cat /sys/kernel/debug/slow_work/runqueue

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: FRV: Implement the GDB remote protocol 'p' command to retrieve a register
Next: freeze when strace X