niDriverThread 'D' wait state

[jtlee]

Hi all,

We're using a NI 6602 board on an Intel atom board w/ hyperthreading.  Since porting to linux we've had pretty good success with this board and with both Ubuntu 10.10 server and Ubuntu 10.10 server + xfce desktop. 

What although performance generall seems good I'm seeing 'Top' load values in the 7+ range.  The cpu load is fine..typically 10-30% with the occasional spike. This is expected.  When investigating the load value I found a bunch of uninterruptble niDriver threads...

Command:

     ps axl | awk '$10 ~ /D/'

Result:

1	0  7626	2  20   0	0	0 nNIKAL D	?	0:00 [niDriverThread]
1	0  7627	2  20   0	0	0 nNIKAL D	?	0:00 [niDriverThread]
1	0  7628	2  20   0	0	0 nNIKAL D	?	0:00 [niDriverThread]
1	0  7629	2  20   0	0	0 nNIKAL D	?	0:00 [niDriverThread]
1	0  7630	2  20   0	0	0 nNIKAL D	?	0:00 [niDriverThread]
1	0  7631	2  20   0	0	0 nNIKAL D	?	0:00 [niDriverThread]
1	0  7632	2  20   0	0	0 nNIKAL D	?	0:00 [niDriverThread]
1	0  7633	2  20   0	0	0 nNIKAL D	?	0:00 [niDriverThread]

Does anyone see this is as normal behavior? 

[irwan]

I believe it's fine. AFAIK, those are kernel threads we spawn that ended up blocking "uninterruptible", and those have been known to increase top load value. Uninterruptible sleep just means that you can't interrupt the sleep with a signal. For kernel threads, you're not supposed to interrupt those with signals anyway normally. Doing interruptible sleep in our kernel threads is doable, but it would complicate our software a bit more. But this should be mostly "cosmetic", due to the way the load value is calculated.

[jtlee]

Good to know. Thanks for the info irwan!

[metux]

I believe it's fine. AFAIK, those are kernel threads we spawn that ended up blocking "uninterruptible", and those have been known to increase top load value. Uninterruptible sleep just means that you can't interrupt the sleep with a signal. For kernel threads, you're not supposed to interrupt those with signals anyway normally.

Not quite true, eg. for deregistering the devices or unload the modules, uninterruptible kthreads are really a mess.

Doing interruptible sleep in our kernel threads is doable, but it would complicate our software a bit more. But this should be mostly "cosmetic", due to the way the load value is calculated.

I wonder why you need uninterruptible kthreads at all. All the driver needs to do is writing a few registers (rarely involves any longer sleeps at all) and react on interrupts to copy some data, which should be done via taskslets - doesn't need any dedicated kthreads at all.