On Tue, 12 Jan 1999, Timothy MacDonald wrote:
> The local NT-head ( and decision maker ) here in the office is basing his
> opinion of linux off a sidebar in Windows NT magazine. I think that his
> information is biased and misleading, if not wrong, but I really don't know
> enough about the Linux kernel to argue against it. I have included parts of
> the article below. If someone more knowledgable than I could take a look and
> tell me whether it is correct or not I really would appreciate it!
This article sounds like Microsoft's standard FUD tactics, now applied
to linux. It is really something of a joke, and we should all maintain
our sense of humour as we read it instead of getting incensed. After
all, until a few years ago, Microsoft couldn't even run its own website
on an NT system. Linux, on the other hand, is the darling of the
ISP/website provider community because it scales marvelously well under
rather large loads and is for the most part rock solid stable, as in 100
day uptimes under full load are a rather routine occurence. NT, on the
other hand...
>
> -Start article-
>
> Linux is an active and evolving UNIX implementation that is gaining wide
> acceptance. However, Linux currently has several major limitations that
> prevent it from being a contender in any arena other than the small-server
> segment. Whereas Windows NT and all leading commercial operating systems
> (OSs) implement kernel-mode threads, Linux does not. The Linux scheduler
> does not divide CPU time among threads but among processes. Each process in
> Linux has an implied execution state that, on other UNIX variants, is the
> equivalent of a thread. Thus, a Linux process is similar to a process on
> other UNIX versions that has exactly one thread and cannot create more.
> Linu'x ommision of kernel-mode threads seriously affaces application
> developers' ability to write software that takes maximum advantage of a CPU.
> Linux application developers must use user-mode threads that the system
> implements in user space. User-mode threads are also called cooperatively
> scheduled threads, because kernel schedulers do not divide CPU time among
> the threads. Instead, applications map multiple user-mode threads onto a
> common kernel-mode thread. Then, an application can cause the execution
> focus of the common kernel-mode thread to move around the application's
> code. The drawback of this method is that if a user-mode thread calls a
> kernel function that then blocks the thread ( e.g. by waiting of I/O input
> ), then the application cannot get any other work done. In implementations
> based on kernel-mode threads, blocking one thread of an application does not
> stop other threads that the application created from doing useful work.
Did Bill Clinton write this? Seriously, now...
Theoretical analysis (and all joking) aside, linux >>measurably<<
outperforms "Windows NT and all leading commercial operating systems" on
platforms where both exist, at least to my direct experience. It has
superb feel, especially from userspace, and does an excellent job of
balancing background computation tasks with the demands of foreground
interactive use.
I use linux SMP boxes in a distributed linux beowulf/cluster environment
rather extensively; rarely does the load average on the system(s) drop
below 1 per CPU and it is occasionally as high as 2 or 3, sustained, for
days at a time. This is on code with lots of network traffic and disk
access mixed in as well as just "CPU intensive" code. I've used my
personal 300 MHz dual PII desktop to act as a server to as many as 12
400 MHz dual PII diskless hosts at one time while it and all of these
clients were running background jobs at this load level and while I was
still using my desktop as my desktop console (running X and all that,
playing CD's while I worked, hopping between windows). Flawless
interactive response >>on my desktop<< while my background applications
still got close to 90% of the CPUs (everything else, including NFS
service, really being rather lightweight if you add up the CPU
requirements). Try doing THAT with your "preemptive, threaded" desktop
NT SMP box...and it will just crash.
Back to the humor. I'm pleased to learn from Microsquash's NT organ
that linux "has no threads". This would make it threadbare, I suppose.
Now, I personally don't use threads much (there are lots of ways to
accomplish the same thing, threads being just one paradigm among many)
but I had thought threads existed for linux because when I run "apropos
thread" on a standard Red Hat 5.2 system I get things like:
pthread_create (3thr) - create a new thread
pthread_detach (3thr) - put a running thread in the detached state
pthread_equal (3thr) - compare two thread identifiers
pthread_exit (3thr) - terminate the calling thread
pthread_join (3thr) - wait for termination of another thread
pthread_key_create, pthread_key_delete, pthread_setspecific,
pthread_getspecific
(3thr) - management of thread-specific data
pthread_kill_other_threads_np (3thr) - terminate all threads in program
except c
alling thread
pthread_mutex_init, pthread_mutex_lock, pthread_mutex_trylock,
pthread_mutex_unl
ock, pthread_mutex_destroy (3thr) - operations on mutexes
pthread_mutexattr_init, pthread_mutexattr_destroy,
pthread_mutexattr_setkind_np,
pthread_mutexattr_getkind_np (3thr) - mutex creation attributes
pthread_once (3thr) - once-only initialization
pthread_self (3thr) - return identifier of current thread
... (etc)
I'm really glad to finally learn from an authoritative source that these
routines don't really exist on my system, whatever the man pages might
say. I guess I won't ever try to write code for threads on a linux
system. Thanks, WindowsNT Magazine! You saved me from a possibly
embarrassing mistake! Why, if one of my NT-using friends had been
watching when I tried to code a threaded application, he might of made
fun of me when I learned tragically that linux has no threads, if I had
any NT-using friends...
> Another limitation of the Linux kernel is that the scheduler cannot
> preemt the kernel, as can the scheduler in most modern UNIX variants and NT.
> Because Linux's kernel is not preemtible, it is not as responsive to
> high-priority processes as other OS kernels are. When a high-priority
> process in Linux is ready to execute - for example, after it finishes an I/O
> operation on which it was blocked - the process my wait until the currently
> executing process reaches a well-defined preemption point in the kernel ( if
> that process is executing on the kernel ). On other UNIX systems, the
> high-priority process ( or thread, on other OSs ) would preempt the
> executing thread almost immediately.
My goodness, I didn't know that! And here I thought that linux was the
MOST responsive operating system I have ever used where it counts (and
I've been doing computing fairly intensively for fifteen or twenty years
and have tried quite a few operating systems). I must confess that if
e.g. Solaris (a.k.a. Slowaris) is an example of a "modern Unix variant"
that uses preemptive scheduling, then I would rather be slowly
eviscerated, or perhaps have root canal work done with a nearly
discharged Black and Decker portable drill and dull bit, than have this
"advantage" enter linux. Solaris is the only Unix I've ever used where
running a simple background numerical task actually rendered the console
unusable. However, I would be very interested in seeing actual
benchmarks or even anecdotal reports that show that NT is more
responsive or efficient than linux, now that WindowsNT Magazine has
brought this "flaw" to my attention.
> Finally, the Linux kernel is not reeentrant, which means that only
> one processor in a multi-processor Linux system can execute kernel code at a
> time. This limitation is perhaps the biggest impediment to Linux's
> scalability on multiprocessors, because Linux serializes all its kernel
> services on a multiprocessor, making them run as if they were on a
> uniprocessor. Thus, I/O-intensive applications or applications that make
> heavy use of kernel services will not gain a significant performance benefit
> from executing on a multiprocessor. Linux is not reentrant because Linux's
> creator originally wrote Linux to run on uniprocessors. Making a kernel run
> efficiently on a multiprocessor means implementing relatively complex data
> structure-locking hierarchies, a task that is time consuming on a structure
> that is difficult to retrofit.
Good heavens! By this reasoning, I can conclude that "NT is not
re-entrant and probably can't chew gum and read disk at the same time
because its predecessor was a brain-dead layer (Windows itself) on top
of an obsolete brain-dead layer (DOS) originally written for an 8/16 bit
uniprocessor (the 8088) in a system with no more than a 5 1/4" floppy
drive, 16K of RAM, and an interrupt structure from hell, copied from an
even older program intended to permit access to even bigger floppies on
even slower CPUs."
FUD for thought...
To get serious briefly again, the fact is that the 2.0.x smp kernel (now
what, three years old?) still has a single kernel lock, although it has
improved a bit over the bald statement of "no kernel parallelism" (with
upper and lower half handlers and dma). The 2.1.x (now 2.2.0?) kernel
has fine grained kernel locks and as far as I know parallelizes
non-overlapping parts of the kernel pretty much completely.
I think that this paragraph tremendously overemphasizes the importance
of this in an SMP server, as well -- 2.0.x is quite satisfactory and
cost effective and stable (although perhaps not technically optimal) for
rather large SMP servers, as ISP's well know. That is, although one can
construct specific benchmarks or applications to illustrate the blocking
of the kernel by virtue of having a single lock, in a real multitasking
asynchronous task mix there is almost always other useful work that can
be done on those other "threads" (or plain old processes:-) while
awaiting the kernel lock. That is, even on a server, everything isn't
kernel bound. There are also many server situations where it doesn't
matter how many kernel locks you have, you have to wait for a single
rate-limiting resource (e.g. disk) to complete one access at a time,
simply because you can't parallelize two motions on one disk.
There were some very nice benchmarks of this that were run some years
ago (linked to www.phy.duke.edu/~rgb/linux.html) that showed how the
system instantly scavenges the CPUs to run userspace tasks in these
"holes" where the kernel is blocked awaiting some resource. Search on
Cameron McKinnon's nice turn of phrase: "Look ma, free cycles."
And of course, stability is an important issue that the WindowsNT
Magazine article conveniently forgot. Most corporate managers, properly
informed, wouldn't give a rat's ass about bleeding edge technical
features of an operating system architecture compared to its operational
stability. You lose a hell of a lot more business, or customers, or
whatever it is your server does due to your server crashing under load
than you do because your server is only 80% efficient instead of 90%
efficient when it's up. People are starting to turn in reports of 100+
day uptimes for 2.1.x kernels on smp systems and they are commonplace on
2.0.x smp systems. My own systems stay up until I take them down to
upgrade the kernel or something, almost invariably, regardless of load.
My hardware is three or four times less stable than my software (that
is, three out of four systems failures are due to hardware failures in
my network, not system software crashes) and my hardware isn't THAT bad.
Gee, I wonder what the mean uptime is of one of those fancy old NT SMP
servers under heavy load? Could I run a network of 30 or 40 systems and
not have a crash a month? Wonder what all that downtime costs...
> How do these various limitations affect Linux's chance to compete
> with NT in the enterprise? With adequate OS support, enterprise server
> applications- including Web servers, database servers, and email servers-
> can effectively use multiprocessors. For the next couple of years, Lunix is
> stuck with being a valid choice for only small uniprocessor servers. None
> but the most CPU-intensive Linux applications will scale past one CPU, which
> makes Linux unacceptable as a multiprocessor OS, and therefor as an
> enterprise-class OS.
Ooo, what a surprise! Here I've been, using multiprocessor linux boxes
for YEARS now and only NOW do they tell me that linux can't use multiple
processors effectively? I'm crushed. Really.
Sign me up for NT, lawdy, I've SEEN the light! Gonna be Y2K compliant!
Gonna take out a second mortgage on my home to pay for it, no more of
this free linux for me, no sir! Gotta get me a multiprocessing EMAIL
server and run MICROSOFT mail onit! Gonna run MICROSOFT'S web server,
too! Heckfire, might as well run MICROSOFT'S network as well -- this
TCP-IP stuff is probably more of that Unix standards shit, won't work
atall in a proper MICROSOFT environment, shorely isn't easy to find when
I try to set up the network on my MICROSOFT Windoze 95 box at home.
Cain't trust it. Don't want my ENTERPRISE to fail, oh, no. If it don't
scale it's bound to fail...
Sigh. I hope that I haven't bored any longtime list participants with
this recital. I suppose we should be honored. Microsoft is clearly
stepping up its level of attack, meaning that it must recognize linux as
the threat that it is. Very perceptive of them. However, in the very
short run indeed they'll find that their usual FUD tactics just won't
work against the linux community, because we'll just laugh at them.
Facts is facts, and linux can't be put "out of business", or bought out,
and it doesn't have to win over any fixed number of new businesses a
month to make some sort of sales quota, especially when its retention of
those that DO try it is likely to be, and remain, extremely high for the
simple reasons that it works better and costs less. Far better, far
less. Really, it's not rocket science; even technically illiterate
corporate managers can understand the concepts of price and performance,
of cost and of benefit.
Can you spell "attrition"? I knew that you could...
rgb
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
