Skip to contentSkip to conversation

uninteruptable sleep

DISCUSSION Manfred Spraul 5 participants 11 messages Apr 3, 2001 – Apr 4, 2001

lore
Share & tools
lore

Manfred Spraul

author
#0 lore raw
Quoted 5 lines

ps xl:
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
040 1000 1230 1 9 0 24320 4 down_w D ? 0:00
/home/data/mozilla/obj/dist/bin/mozi

down_w

Perhaps down_write_failed()? 2.4.3 converted the mmap semaphore to a rw-sem.
Did you compile sysrq into your kernel? Then enable it with

#echo 1 > /proc/sys/kernel/sysrq
and press <Alt>+<SysRQ>+'t'

It prints the complete back trace, not just one function name

--
Manfred

#1 lore raw

Re: uninteruptable sleep (D state => load_avrg++)

Sorry if I fork a bit the thread but I'm wondering why the load average is incremented for each D process.

I don't know if the kernel use this information (if yes please let me know).
But some programs like sendmail use this information to sleep when the load is too high (I believe from 12 for sendmail). It makes sence but in the case of D process, the load average give a bad idea of the load because these process don't use CPU.

I use GFS to share a filesystem on several nodes.
The file locking use real IO and so when you ask for a lock, if the lock is already owned, you fall in a D state. This differs from what a local filesystem does but IMHO makes sense for a distributed filesytem like GFS.

Christophe

Quoted 27 lines · On mar, 03 avr 2001 18:40:53 Manfred Spraul wrote:
Quoted 5 lines

ps xl:
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
040 1000 1230 1 9 0 24320 4 down_w D ? 0:00
/home/data/mozilla/obj/dist/bin/mozi

down_w

Perhaps down_write_failed()? 2.4.3 converted the mmap semaphore to a rw-sem.
Did you compile sysrq into your kernel? Then enable it with

#echo 1 > /proc/sys/kernel/sysrq
and press <Alt>+<SysRQ>+'t'

It prints the complete back trace, not just one function name

--
Manfred

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 8 lines
Christophe Barbé
Software Engineer
Lineo High Availability Group
42-46, rue Médéric
92110 Clichy - France
phone (33).1.41.40.02.12
fax (33).1.41.40.02.01
www.lineo.com
#2 lore raw

Re: uninteruptable sleep (D state => load_avrg++)

Quoted 2 lines

The file locking use real IO and so when you ask for a lock, if the loc= k is already owned, you fall in a D state.

That seems odd. They should be using interruptible sleeps so you can interrupt the task waiting for the lock, surely.

#3 lore raw

Re: uninteruptable sleep (D state => load_avrg++)

In reply to christophe barbe

The sleep should certainly be interruptible and I that's what I said to the GFS guy. But what the reason to increment the load average for each D process ?

Thanks,
Christophe

Quoted 12 lines · On mer, 04 avr 2001 13:15:52 Alan Cox wrote:
Quoted 2 lines

The file locking use real IO and so when you ask for a lock, if the loc= k is already owned, you fall in a D state.

That seems odd. They should be using interruptible sleeps so you can interrupt the task waiting for the lock, surely.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 8 lines
Christophe Barbé
Software Engineer
Lineo High Availability Group
42-46, rue Médéric
92110 Clichy - France
phone (33).1.41.40.02.12
fax (33).1.41.40.02.01
www.lineo.com
#4 lore raw

Re: uninteruptable sleep (D state => load_avrg++)

Quoted 3 lines

The sleep should certainly be interruptible and I that's what I said to t= he GFS guy.
But what the reason to increment the load average for each D process ?

D indicates short term I/O wait. This is how unix has always computed the laod average.

#5 lore raw

Re: uninteruptable sleep (D state => load_avrg++)

In reply to christophe barbe
Quoted 3 lines · christophe barbe

The sleep should certainly be interruptible and I that's what I said to the GFS guy. But what the reason to increment the load average for each D process ?

from a philosical POV: they are processes that will be runnable as soon as the kernel returns to them.

no idea if there are technical reasons for it.

Quoted 3 lines

Thanks,
Christophe

--paulj

#6 lore raw

Re: uninteruptable sleep (D state => load_avrg++)

In reply to christophe barbe

<skip>
I've unfortunately no significant Unix culture.
I'm certainly young enough to be excused and by luck Linux shows me the road to the hacker heaven. So now I move forward the good direction, trying to understand the POSIX stuff .... </skip>

Quoted 1 line

From me, a POV without technical reasons is not a philosical one but more certainly an historical one.

Process that will be runnable are not participating to the load so why incrementing the load average.
Moreover if a process should be in state D only for a short time, the influence of the incrementation should be near null for an AVERAGE value. So why doing that (I mean load++) if there's an influence only when a process stay in a D state for a long time (= when the only effect is to distort the load measure) ?

What's the technical reason behind this load_avrg++ ???

Christophe

Quoted 17 lines · On mer, 04 avr 2001 16:20:04 Paul Jakma wrote:
Quoted 3 lines · christophe barbe

The sleep should certainly be interruptible and I that's what I said to the GFS guy. But what the reason to increment the load average for each D process ?

from a philosical POV: they are processes that will be runnable as soon as the kernel returns to them.

no idea if there are technical reasons for it.

Quoted 3 lines

Thanks,
Christophe

--paulj

Signature · 8 lines
Christophe Barbé
Software Engineer
Lineo High Availability Group
42-46, rue Médéric
92110 Clichy - France
phone (33).1.41.40.02.12
fax (33).1.41.40.02.01
www.lineo.com
#7 lore raw

Re: uninteruptable sleep (D state => load_avrg++)

Quoted 2 lines · christophe barbe

From me, a POV without technical reasons is not a philosical one but more certainly an historical one.

there may be (and indeed probably are) good technical reasons, however i am not well enough informed to say what they are.

Quoted 2 lines

Process that will be runnable are not participating to the load so why incrementing the load average.

As i understand it:

load avg by nature is a measure of how many processes are 'runnable' (ie waiting to run) over time.

a process waiting for the kernel to complete IO will indeed be runnable as soon as the kernel is finished.

instead of waiting for CPU time (as with processes marked R), instead these processes are waiting for kernel to complete.

Quoted 3 lines

Moreover if a process should be
in state D only for a short time, the influence of the incrementation should be near null for an AVERAGE value.

because the number of processes asleep, waiting on kernel to complete IO may reasonably be considered to be a load.

imagine a box with a bunch of processes that do almost nothing but call on the kernel to do IO. If you only count the runnable state towards load_avg then your load_avg will be very low, even though your box is swamped - you are ignoring the work of the kernel.

if you count D towards load_avg then it will reflect this abstract 'load' concept more accurately.

Ie, counting D towards load_avg is a way of taking kernel IO work into account when calculating the load average figures.

Quoted 4 lines

What's the technical reason behind this load_avrg++ ???

Christophe

--paulj

#8 lore raw

Re: uninteruptable sleep (D state => load_avrg++)

In reply to christophe barbe
Quoted 10 lines · On mer, 04 avr 2001 17:05:05 Paul Jakma wrote:

imagine a box with a bunch of processes that do almost nothing but call on the kernel to do IO. If you only count the runnable state towards load_avg then your load_avg will be very low, even though your box is swamped - you are ignoring the work of the kernel.

if you count D towards load_avg then it will reflect this abstract 'load' concept more accurately.

Ie, counting D towards load_avg is a way of taking kernel IO work into account when calculating the load average figures.

ok I'm convinced.
And a measure can't be perfect.

Thank you,
Christophe

Signature · 8 lines
Christophe Barbé
Software Engineer
Lineo High Availability Group
42-46, rue Médéric
92110 Clichy - France
phone (33).1.41.40.02.12
fax (33).1.41.40.02.01
www.lineo.com
#9 lore raw

Re: uninteruptable sleep (D state => load_avrg++)

In reply to christophe barbe
Quoted 3 lines · christophe barbe

The sleep should certainly be interruptible and I that's what I said to the GFS guy. But what the reason to increment the load average for each D process ?

OK, the Unix history goes something like this. Synchronization was achieved using two primitives, sleep() and wakeup(). These guys rendezvous'd on a wait channel, which was simply an 'int', and by convention was actually the address of a data structure (yes I know int and pointers aren't the same, this is a long time ago, OK ? :-).
Anyway, when you called sleep, you also had an associated priority. Priority values less than PZERO were "high" priority, and >= PZERO were "low" priority. sleeping above PZERO was interruptible, and processes sleeping at this priority did not count towards the load. The idea was to use this for events that potentially might never happen. Sleeping at a priority < PZERO was intended to be used for things that are absolutely 100% guaranteed to happen, preferably sometime very soon. Disk I/O (real disks, not NFS) fell into this category, and hence it counts towards the load since this could be deemed a "fast wait" state, and the process is nominally runnable. All a bit hand-wavy I know, but it worked well enough.

The really important part of all this is that you should never sleep uninterruptibly for anything that you cannot absolutely guarantee will happen, otherwise you wind up with a stuck process.

Regards,

Tim

Signature · 4 lines
Tim Wright - [email protected] or [email protected] or [email protected]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
#10 lore raw
In reply to Manfred Spraul

This problem seems to be related with the recent post from David Howells <[email protected]> with the subject "rw_semaphore bug".

Christophe

Quoted 27 lines · On mar, 03 avr 2001 18:40:53 Manfred Spraul wrote:
Quoted 5 lines

ps xl:
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
040 1000 1230 1 9 0 24320 4 down_w D ? 0:00
/home/data/mozilla/obj/dist/bin/mozi

down_w

Perhaps down_write_failed()? 2.4.3 converted the mmap semaphore to a rw-sem.
Did you compile sysrq into your kernel? Then enable it with

#echo 1 > /proc/sys/kernel/sysrq
and press <Alt>+<SysRQ>+'t'

It prints the complete back trace, not just one function name

--
Manfred

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 8 lines
Christophe Barbé
Software Engineer
Lineo High Availability Group
42-46, rue Médéric
92110 Clichy - France
phone (33).1.41.40.02.12
fax (33).1.41.40.02.01
www.lineo.com