lkml.org 
[lkml]   [2000]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site