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!
>
> -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.
that's correct, but it is all baloney. Any 'process' under linux can
create more processes, or threads can create more threads. All they had
to do was to look at the man pages and docs for pthreads, and specifically
look at pthread_create. Kernel level processes work just fine... they are
still lightweight, they can be fired off quick and can exit quickly, they
can create other processes in a hiarchical manner... they are scheduled
concurrently on a machine with multiple processors. I've got several
thread applications running here and teach an undergraduate and graduate
course in doing parallel programming using posix threads under linux.
> 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.
Eh? someone is lost. And it isn't the linux thread folks. Linux threads
are completely independent execution-wise. They can create other threads,
coordinate using mutex locks to protect shared memory objects, they run
concurrently (at least mine do where I keep a quad-cpu xeon running all
4 processors 100% of the time with a _single_ application.
> 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.
That is totally incorrect. A linux thread is a kernel process. Any
process can block for I/O without blocking other processes. Whomever
wrote that is totally out to lunch...
> 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.
> 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.
I almost lost my cookies there. This is an NT person writing this? and he
is talking about response time being better than on linux. hahaha...
very funny. And dead wrong too, fortunately...
> 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.
> 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.
Perhaps you should refer this person to the stuff going on in 2.1 where
this is all completely wrong.
> 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.
>
>
linux is doing _so_ badly on SMP stuff that major computer vendors now
recomment linux on large SMP server configurations because the performance
is _better_ than with NT. IE gateway, dell, compaq, etc...
> ----end article---
>
> Painstakingly typed by me ( Timothy MacDonald ) from the December 1998 issue
> of WindowsNT magazine ( page 122 ). Please excuse any typos.
>
> Thanks for your time,
>
> Timothy MacDonald
> [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]
>
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
