> segment. Whereas Windows NT and all leading commercial operating systems
> (OSs) implement kernel-mode threads, Linux does not. The Linux scheduler
False.
> 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 shows a complete misunderstanding. Linux doesn't have the messy thread
versus process split that other systems do. You just pick what you want to
share at any given point.
> Linu'x ommision of kernel-mode threads seriously affaces application
> developers' ability to write software that takes maximum advantage of a CPU.
False
> Linux application developers must use user-mode threads that the system
> implements in user space. User-mode threads are also called cooperatively
False
> the threads. Instead, applications map multiple user-mode threads onto a
> common kernel-mode thread. Then, an application can cause the execution
False in Linuxthreads
> 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
False
> 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
True. However the worst case responses in Linux are materially faster than
NT anyway.
> 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
At the instant the other process in kernel state pauses because it waits
on anything. In practice non issue. Unix has been done this way since V1
its faster than the million locks alternative. Only an RTOS has other
issues with this.
> 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
False for 2.2, mostly true for 2.0
> uniprocessor. Thus, I/O-intensive applications or applications that make
> heavy use of kernel services will not gain a significant performance benefit
Partly False - I/O intensive processes sleep on the I/O, that lets other threads
execute kernel space.
> 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.
See 2.2.
> can effectively use multiprocessors. For the next couple of years, Lunix is
He can't even spell it right 8)
> 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.
I believe Mr Miller is at 20 processors on the sparc, and there are production
6 processor x86 machines running Linux flat out for big web servers.
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
