On Tue, Jan 12, 1999 at 02:05:03PM -0600, 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!
Here goes...
>
> -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.
Partly true. Linux assigns a PID for each new thread. But Linux is effective
enough so that creating a thread (which creates a new PID) takes roughly 0.3
ms compared to 0.9 ms on NT, on the same machine (source, Linux journal issue 57).
Conclusion: Linux's still faster, although you could argue that Linux doesn't
create threads (although the processes are _exactly_ similar to threads in all
aspects).
> Linu'x ommision of kernel-mode threads seriously affaces application
> developers' ability to write software that takes maximum advantage of a CPU.
On SMP, the fact that each thread has it's own PID assures that threads migrate
over CPUs seamingless, the same way that processes do.
It's probably simpler than it is on NT, but that is only a benefit. (except maybe
for the marketing department, that will have fewer fancy words to throw around, but
that never stopped them did it?)
> 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.
In a way true. You _can_ create user-mode threads, if you really want to. But the
default in Linux (2.0.x and newer kernels, with glibc) is the kernel threads mentioned
above.
> 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.
The thing about the drawback of user mode threads is true. And it will hit you
if you specifically install a user-mode thread library and use that. But you will
have to do active work, to get this drawback. The default mode of operation is
kernel mode threads.
> 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.
You can't preempt an interrupt. But interrupt handlers are split in parts, a
time-critical part that cannot be preempted, and the main-part which is scheduled
like any other task.
> 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.
Don't know about what other UN*Xes do. It's true that linux is not a real-time
kernel, but neither is most UN*Xes, and NT for sure isn't either.
I have no problem streaming sound to my sound-card (which needs good response from
the kernel due to a crappy sound-card) and running 5-10 compile processes concurrently.
> 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.
True especially on 2.0.x kernels. This has improved _very_ much on 2.2. The 2.2
kernels can have one CPU accessing the disks while the other manages network etc.
But why does NT people mention this ? NT is either a little worse or a little
better than 2.0.x, depending on how many service-packs you've installed.
2.2.0 should kick the guts out of the NT scheduler in this matter (as well).
> 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.
True. But think about it: This argument says, if you put 10 CPUs in a machine with
a slow I/O subsystem, you'r I/O doesn't improve.
Well it's hard to argue with that.
In general, your disks does not speed up no matter how many CPUs you put in your
system.
Regardless of what OS you run.
> 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.
True. 2.0.x does crude SMP. But as mentioned earlier, 2.2.x makes up for this.
Linux 2.2.x is truely a very well performing SMP kernel.
> 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.
Allready now, ISPs run Linux on a large scale. Why ? Well I guess it's because
it's slow and cannot scale well and cannot handle large servers.
Hotmail does NOT run NT. Ofcourse, it doesn't run Linux either, but NT can for sure
not scale on large servers. Remember, microsoft tried to run Hotmail on NT. They
couldn't.
This was not because they couldn't afford another server.
> 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.
PC architecture is not for the large enterprise applications that are extremely heavy
on I/O.
This is independent of OS, although you do tend to get good performance from Linux on
large
PCs.
But you can actually run Linux on your UltraSparc. And it's said to run well.
At my site we use a Pentium 133 MHz (running Linux) as our router and mail-server. We
have around
250 active users. The machine delivers around 2000 mails per day, and routes around
60 GB of data.
It also keeps a log of routed network connections initiated on certain ports. Ofcourse
it also runs
primary DNS and NTP server, but those two aren't heavy.
I guess that speaks pretty much for itself, although the server isn't a multiprocessor
:)
................................................................
: [EMAIL PROTECTED] : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob �stergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
