Messages in this thread |  | | | Date | Wed, 1 Mar 2000 11:30:45 +0200 | | From | Tuukka Toivonen <> | | Subject | Re: Linux kernerl preemptive ?? |
| |
On Tue, 29 Feb 2000, Aneesh Kumar K.V wrote:
> Actually i didn't get the point . You say kernel is not preemptive but it > can yield to other process when it is waiting for some resources . Well
Ie. kernel is multitasking "cop-operatively" while in kernel mode. Most system calls require only so little time that it doesn't matter to multitask fully then. Only if the system calls need to wait for something (an IRQ, for example) they yield another process while waiting.
> then why it is not made preemptive .
That requires locking all data that is used, and _that_ means lower performance. It means, of course, also somebody to write the code.
>Is SMP used to multiprocessor machine
Yes.
(However, the kernel has to be compiled to support SMP. If you have just some random precompiled kernel image, it might not support SMP).
> . Do it have anything to do with preemtion .
Well, yes in a way. While CPU#1 is running in kernel mode, it has acquired locks that prevent CPU#2 from running in kernel mode too. Or rather, that was the case with 2.0.0 kernel. This is called (very) coarse-granularity locking.
In time it is supposed that the locking is tuned to more fine-granularity locking. It means that some process running in kernel mode on CPU#1 has locked only parts of the kernel, and other CPUs can use the all unlocked parts freely, simultaneously. For example, with kernel 2.2.x it's much better already. In practice this means that the kernel becomes more scalable -- additional CPUs are used more effectively.
Now, one would suppose that fine-granularity locking is the goal. Many commercial operating systems do that, eg. IRIX. It is supposed to give the best scalability. However, this has a hit on performance especially on systems with just one or two CPUs (like most PCs these days).
Some people (mainly Larry McVoy) have proposed that this shouldn't be done. He has proposed another way how scalability should be achieved. But since you didn't ask that, I stop my story here.
Now the next poster may freely correct errors in my explanation.
Btw: i found an interesting URL at http://www.cs.unc.edu/~dewan/242/s99/notes/trans/node1.html.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |