Why I like preemtible kernels.

jtshaw · 01-23-2004, 08:56 AM

I just decide to try something I haven't done in linux for a long time. We were having a discussion at work about solaris vs. linux thread management. Somebody was arguing that a forking program gone bad in solaris would bring the system to a halt while in linux it would eventually kill them all and the system would be fine. So I wrote a small program I call nastyfork to test this theory:

Code:

#include <sys/types.h>
#include <unistd.h>
#include <limits.h>

int main(void)
{
   unsigned long i;
   for (i=0;i<=LONG_MAX;i++)
   {
      if(!fork())
      {
         break;
      }
   }
   return 0;
}

When I ran this on the 2.4 kernel the same basic thing happen that happened in solaris, the machine became unusable. So I was bored this morning and I brought nastyfork back out and ran it on my 2.6.1 kernel with the preemtible kernel enabled. To my surprise it runs happily up to the point where linux says it can't fork anymore, and although my processor usage reads 100% and I can't run anything because "bash: fork: Resource temporarily unavailable" my GUI interface is still VERY responsive, which is a step in the right direction.

And yes... I am THAT bored.

infamous41md · 01-23-2004, 11:02 AM

another good reason is that it forces (lazy)module writers to write re-entrant code.

jtshaw · 01-23-2004, 11:06 AM

Very good point.

whansard · 01-23-2004, 11:13 AM

i'm running that code right now on 2.4.23-ck1 with the desktop low latency patches
that i don't really understand, but the system is plenty responsive. how long
should it take to die?

it takes about 10 seconds to get up to 14,000 something tasks, and then adds
no more. cpu usage says 100% as i'm typing this.

jtshaw · 01-23-2004, 11:25 AM

The low latency patch might take care of it, I was running it on a very early 2.4 kernel when it made the system unresponsive.

whansard · 01-23-2004, 11:31 AM

i was just testing it on a different kernel for you.

84 010-ckbase.diff.bz2 4 012-rl2dt.diff.bz2 4 014-vhz.diff.bz2
4 011-readlatency2.diff.bz2 8 013-j64.diff.bz2

those are the kernel patches i have added in.

Hko · 01-23-2004, 11:41 AM

I tried this simpler forkbomb.c, which could be even a little nastier because it doesn't stop after LONG_MAX.

Code:

#include <unistd.h>

int main()
{
     for(;;) fork();
     return 0;
}

I tried it on the latest 2.4 kernel (2.4.24) without any patches, and it even made me use the power switch. On 2.6.1 I can type this post as if nothing is happening. "top" on another xterm doesn't update its display anymore though...

jtshaw · 01-23-2004, 12:00 PM

Ya, that is definitly nastier, the one I wrote might give the 2.4.24 kernel a chance or recover... but it will take a while.

kev82 · 01-25-2004, 09:18 AM

ive not done much testing but video capture seems to be rubbish in a preemptible 2.6.0 even in single user mode audio and video go out of sync almost immediatly where they dont in 2.4.22, but this could be due to new v4l/bttv stuff when i have time i'll test it properly.

btw i know 2.4.22 and 2.6.0 have security problems, and im not using them anymore

jtshaw · 01-25-2004, 10:08 AM

Ya, should be easy to get a 2.6.1 kernel with and without the peremptible part and see if it makes a difference. Perhaps the bttv modules weren't update..

whansard · 01-25-2004, 01:12 PM

Quote:

Originally posted by Hko
I tried this simpler forkbomb.c, which could be even a little nastier because it doesn't stop after LONG_MAX.

Code:

#include <unistd.h> int main() { for(;;) fork(); return 0; }

I tried it on the latest 2.4 kernel (2.4.24) without any patches, and it even made me use the power switch. On 2.6.1 I can type this post as if nothing is happening. "top" on another xterm doesn't update its display anymore though...

i tried that one, and i couldn't start an tasks, and i couldn't really exit any either.
i exited x, and couldn't get a prompt back. i typed df, on a different terminal,
no response. i could suspend a task, but not end one. i hit reset after about
10 minutes.