> 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.
> 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.
> 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.
> 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.
> 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.
>
>
> ----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]
>
I feel sorry for you, because it's really a pain to write down things
like this ;-)
Well, as far as I know the 2.0 series of kernels have a global lock
around all the kernel code wich effectively implies that only one
proccess could be in the kernel at the same time this is the so
called global lock. Now int the 2.1 and 2.2 series the kernel has
been moved to a fine grained lock wich implies that only one proccess
can be in the same locked kernel code, but the locked code is a
little part of the kernel, not the whole kernel, so the speed is
better.
About the threads part; I don't really understand the NT's text (and
so other things about NT). It's true that the threads in linux are in
user space, but they are like any other proccess and the time is
divided by the scheduler, not by the app. If a program spawns two
threads there will be (if I remember correctly) a total of four
processes two for the threads, + one for the program + one for a
thread spawned by linuxthreads in glibc which controls the signals
and locks between the threads, this "control thread" is closed
automatically when all the other threads have finished.
This effectively allows the programmers to spawn threads like in any
other operating systems and to take advantage of multiple cpus, it's
true that the scheduler divides time among processes, but a thread is
a process, so the scheduler works the same. If any thread gets stuked
in an IO op. the other threads gets their amount of time by the
scheduler and works just as OK as the other processes (if no thread
is waiting for the end of the blocked thread; in this case two
threads are blocked)
About the high priority you can visit the home page of LinuxRT (Linux
RealTime) something that NT will never get. Just keep the mouse
button pressed in the root window and watch the packet looses and
apps paused.
The current linux kernel althought not RealTime it's more responsive
to high-priority process and to the rest of the system. Using the
parallel port (Zip, scanner,...) and you can see the mouse movement
become jerky, and the net io speed , well, the net io doesn't exist
in this environment... it just seem to disapear.
In linux I can copy to and from a parallel Zip at full speed (EPP 32)
and the net speed is as great as before, and the mouse is also OK.
Well, Linux is not for the weak hearts, and with M$ you get a OS that
just does the job. In Linux this job is also done, but optimized,
with less mem and more speed.
NT's minimun requirements for booting a system were a 486 with 24
megs of RAM, well at home I have a 386sx20 with 4, yes, four megs of
ram and 12M of swap acting as a sendmail, nfs, telnet, ftp, irc,
router, ip-masquerade, with two 50M hd with software raid0, and
kernel 2.2.0-pre6. At the moment I don't have any problem with this,
there are moments that the hd scracth like a mad man and load gets up
to 6 and 7 but the machine is rock solid, not very fast but rock
solid.
I bet your local NT-head to install NT in such machine...
...and to make it booting OK ;-)
P.D. I don't want to speak about security (:$DATA, pptp,
getadmin,...) stability (how many hours is your NT's max uptime,
linux uptimes are days, months and some with patient to not to
upgrade the kernel, year), and support for standards and protocols...
\_/, _
| @___oo ( Jorge Nerin
/\ /\ / (___,,,}_--~
) /^\) ^\/ _) ~__ [EMAIL PROTECTED]
) /^\/ _) (_
) _ / / _) ( [EMAIL PROTECTED]
/\ )/\/ || | )_)
< > |(,,) )__)
|| / \)___)\
| \____( )___) )___
\______(_______;;; __;;;
Greeetings from Zaragoza (Spain)
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
