Prev: FRV: Implement the GDB remote protocol 'p' command to retrieve a register
Next: freeze when strace X
From: Theodore Ts'o on 9 Jun 2010 14:40

My laptop is running 2.6.35-rc2 (plus a few patches) and after not quite
four hours of beeing booted (3:45 to be precise), top shows that kslowd
has accumulated as surprising amount of CPU time. From top display:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6173 root 15 -5 0 0 0 S 6 0.0 10:42.91 kslowd001
1219 root 15 -5 0 0 0 S 5 0.0 11:00.68 kslowd000
1765 root 15 -5 0 0 0 S 5 0.0 10:59.20 kslowd002
6784 root 15 -5 0 0 0 S 4 0.0 10:34.37 kslowd003
4946 root 20 0 144m 34m 17m S 3 0.9 2:24.62 Xorg

This came up because I was trying to figure out why mouse response was
being so jerky. There aren't that many users of slow-work, and given
that I'm not using cifs, fscache, gfs2, my suspicions are falling on
drivers/gpu/drm/drm_crtc_helper.c (Would this be something that would be
in use on a Lenovo T400 laptop?)

Is there any way to easily see what is scheduling themselves to use the
slow workqueue?

Thanks,

- 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: David Howells on 9 Jun 2010 15:00
Theodore Ts'o <tytso(a)mit.edu> wrote:

> Is there any way to easily see what is scheduling themselves to use the
> slow workqueue?

Slow work has debugging. Turn on:

CONFIG_SLOW_WORK_DEBUG=y

then do:

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/
From: David Howells on 9 Jun 2010 15:10
David Howells <dhowells(a)redhat.com> wrote:

> > Is there any way to easily see what is scheduling themselves to use the
> > slow workqueue?
>
> Slow work has debugging. Turn on:
>
> CONFIG_SLOW_WORK_DEBUG=y
>
> then do:
>
> watch -n0 cat /sys/kernel/debug/slow_work/runqueue

I documented this, of course. Look in:

Documentation/slow-work.txt

in section "VIEWING EXECUTING AND QUEUED ITEMS".

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/
From: Dave Airlie on 13 Jun 2010 04:30
On Thu, Jun 10, 2010 at 4:36 AM, Theodore Ts'o <tytso(a)mit.edu> wrote:
>
> My laptop is running 2.6.35-rc2 (plus a few patches) and after not quite
> four hours of beeing booted (3:45 to be precise), top shows that kslowd
> has accumulated as surprising amount of CPU time. �From top display:
>
> �PID USER � � �PR �NI �VIRT �RES �SHR S %CPU %MEM � �TIME+ �COMMAND
> �6173 root � � �15 �-5 � � 0 � �0 � �0 S � �6 �0.0 �10:42.91 kslowd001
> �1219 root � � �15 �-5 � � 0 � �0 � �0 S � �5 �0.0 �11:00.68 kslowd000
> �1765 root � � �15 �-5 � � 0 � �0 � �0 S � �5 �0.0 �10:59.20 kslowd002
> �6784 root � � �15 �-5 � � 0 � �0 � �0 S � �4 �0.0 �10:34.37 kslowd003
> �4946 root � � �20 � 0 �144m �34m �17m S � �3 �0.9 � 2:24.62 Xorg
>
> This came up because I was trying to figure out why mouse response was
> being so jerky. �There aren't that many users of slow-work, and given
> that I'm not using cifs, fscache, gfs2, my suspicions are falling on
> drivers/gpu/drm/drm_crtc_helper.c (Would this be something that would be
> in use on a Lenovo T400 laptop?)
>
> Is there any way to easily see what is scheduling themselves to use the
> slow workqueue?

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?

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: tytso on 13 Jun 2010 16:00
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.

- Ted


commit bd69ab2e31a329ad9d660e23a1dc806ae0a3afbd
Author: Theodore Ts'o <tytso(a)mit.edu>
Date: Sat Jun 12 21:54:03 2010 -0400

Add slow workqueue debuging for drm_crtc_helper.c

diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
index 9b2a541..e536e80 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -860,6 +860,16 @@ static void output_poll_execute(struct slow_work *work)
}
}

+#ifdef CONFIG_SLOW_WORK_DEBUG
+static void drm_op_desc(struct slow_work *work, struct seq_file *m)
+{
+ struct delayed_slow_work *delayed_work = container_of(work, struct delayed_slow_work, work);
+ struct drm_device *dev = container_of(delayed_work, struct drm_device, mode_config.output_poll_slow_work);
+
+ seq_printf(m, "DRM_CRTC_HELPER: %s", dev->devname);
+}
+#endif
+
void drm_kms_helper_poll_disable(struct drm_device *dev)
{
if (!dev->mode_config.poll_enabled)
@@ -917,4 +927,7 @@ EXPORT_SYMBOL(drm_helper_hpd_irq_event);

static struct slow_work_ops output_poll_ops = {
.execute = output_poll_execute,
+#ifdef CONFIG_SLOW_WORK_DEBUG
+ .desc = drm_op_desc,
+#endif
};

--
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/
 |  Next  |  Last
Pages: 1 2 3
Prev: FRV: Implement the GDB remote protocol 'p' command to retrieve a register
Next: freeze when strace X