Linux Users

Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.
Highlighted

niDriverThread 'D' wait state

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? 

0 Kudos
Message 1 of 4
(1,653 Views)
3 REPLIES 3

Re: niDriverThread 'D' wait state

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.

0 Kudos
Message 2 of 4
(1,159 Views)

Re: niDriverThread 'D' wait state

Good to know. Thanks for the info irwan!

0 Kudos
Message 3 of 4
(1,159 Views)

Re: niDriverThread 'D' wait state

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.

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 4 of 4
(379 Views)
Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.