Date: Mon, 12 Aug 1996 00:17:55 -0700 From: "Michael L. VanLoon -- HeadCandy.com" <michaelv@HeadCandy.com> To: A JOSEPH KOSHY <koshy@india.hp.com> Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD vs. NT Stability Message-ID: <199608120718.AAA14917@MindBender.HeadCandy.com> In-Reply-To: Your message of Mon, 12 Aug 96 12:21:27 %2B0530. <199608120651.AA091782688@fakir.india.hp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Sometime back there was a posting comparing the behaviour of FreeBSD and
>NT wrt a test program that created lots of processes and stressed the OS.
>(I've unfortunately lost the original mails).
>
>It struck me that the NT version of the program was using `CreateThread()'
>while the Unix (FreeBSD) version was using `fork()'.
Right... This is The Right Thing To Do on NT. NT has no real
equivelant of fork in the Win32 API. (There is a fork in the Posix
subsystem, but that's largely for decoration, anyway...) The
alternative is to make NT use CreateProcess, which is really clumsy
since it's basically the equivelant of the Unix fork/exec. So, in
spite of the fact that it's different, remember that it has to be
different, since these are two vastly different OS'.
>Now I don't know much about NT internals, but it seems to me that the NT
>approach wouldn't lead to as many process context switches since the threads
>would be sharing the same address space. Therefore the load on the VM system
>would be no different from having 1 process.
Well, yes and no. If the various threads allocate memory while
thrashing, this memory is going to be used in the same way that Unix
uses it. Added to the fact that both systems use copy-on-write and
shared text segments, so the only thing that will not be shared in the
Unix fork method is the freshly allocated/written memory, which isn't
shared under NT threads either, and a small amount of additional
overhead for each process.
On the other hand, context switching among multiple processes is not
as efficient as context switching among multiple threads with shared
address space. This is where Unix loses. On the other hand, there
are threads packages for Unix. I don't know if FreeBSD has explicit
kernel support for threads, to make them more efficient, but it might
be something worth investigating.
And, on a third hand :-), there has been at least one paper written
that says NetBSD (and this should also apply to FreeBSD) had a more
efficient context switching response than NT (and OS/2, I think),
anyway, so it might even out in the end. But this advantage could go
away somewhat for two reasons: NT 4.0 is more efficient for several
reasons than older versions of NT, and FreeBSD might slow down a
little once all the SMP stuff makes it into the main code base.
>The poster reported a slowdown on NT with many threads but no crashes, which
>seems logical since multiple threads would consume CPU time, and not placing
>a load on the VM would mean it wouldn't crash :-).
I think "not placing a load" is exagerating. As stated above, the VM
usage should be very similar. The context switching overhead,
however, might hurt Unix with a ton of processes.
>So my question is: how does NT behave when it has to schedule between a
>large number of processes each with its own process context, VM, page tables
>etc? Conversely how does the unix program behave when linked with -lpthreads
>and with `fork()' replaced with `pthread_create()'?
Both would be good questions to investigate. But, remember that NT is
optimized for threads, and a non-threaded multi-process application on
NT is a badly written NT application. So, such findings have to be
taken with a grain of salt. But it would be good to compare a _good_
Unix threads implementation running this test against running it on NT
Server 4.0, on similar hardware.
-----------------------------------------------------------------------------
Michael L. VanLoon michaelv@HeadCandy.com
--< Free your mind and your machine -- NetBSD free un*x >--
NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3,
Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32...
NetBSD ports in progress: PICA, others...
Roll your own Internet access -- Seattle People's Internet cooperative.
If you're in the Seattle area, ask me how.
-----------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608120718.AAA14917>