> >On Thu, 21 Jan 1999, Yogesh Bansal wrote:
> >
> >> 1. kernel is not preemptive. ie even a higher priority user thread cant
> >> cause another thread to be swapped if the other thread is presently running
> >> in privileged/kernel context.
> >
> >Not true. All things that are not running with interrupts disabled can be
> >preempted.
>
> Ahem. This is referring (in BOTH instances) to process/thread level. No
> 'thread' can. if you want to include via hooking an interrupt so be it, but
> don't you think that's a little beyond the argument on either system?
Yes, you're right. I didn't read the original statement very closely.
Processes that are running in the kernel only give up to other threads by
having 'if(need_reschedule) schedule()' or other similar coroutine calls.
The statement seems to imply that this is a problem. It's not. Interrupts
and bottom halves can preempt, which is what's important for tasks where
you care about such things, namely real-time. Many of the people who care
about real-time will tell you that trying to muck with the kernel to do
things differently is not really a win. So no, it's not "beyond the
argument", as the implied "Linux is missing an important feature" of the
original statement is wrong.
> >> 2. kernel is not reentrant. ie.only one thread in kernel context at a
> time.
> >
> >Pfft. This is absurd. Every process that is blocked on I/O is _in kernel
> >context_. This is the way UNIX works.
>
> Pfft.. Oh dear, it's been weeks since I laughed. I think this was referring
> to re-entrancy of and in the kernel.
Excuse me? When a process calls a system call, the process is running _in
the kernel_ (see below). Multiple processes can call the same system
calls. If the machine is SMP, two processes can call the same system call
simultaneously. What, pray tell, is your definition of reentrant?
> >> 3. kernel is not multi processing in the sense that on multiprocessor
> >> systems it will run on only one cpu at a time.
> >
> >And this is even more absurd. SMP is _symmetric_. Kernel runs on all
> >processors _by definition_. There may be some confusion here with respect
> >to lock granularity though. The very first SMP kernels had a single lock
> >that protected most data structures, which drastically limited kernel
> >concurrency. Current kernels have more fine-grained locking that allow
> >much better concurrency and therefore better scaling.
>
> Can someone more knowledgeable explain to me whether or not the KERNEL runs
> on more than one processor.. I am curious, because that would be
> interesting to hear.
The kernel is more like a library than a process. Calling the kernel is
not a task switch - it's just a fancy function call (a software interrupt
that does a ring 0 transition). Task switches happen when schedule()
decides to call switchto(). When a process makes a system call, the system
call is still in the process context, so it makes sense to say 'a process
is in the kernel'. And this isn't just semantics - the stack the kernel
uses is allocated per-process so the kernel's execution state is tied to
the process.
In the same way that multiple processes can call the same function in the
C library simultaneously, multiple processes can call the same syscalls.
By having the kernel use stacks attached to the process, the simpler parts
of reentrancy are not a problem, in the same way the shared image of libc
doesn't have a problem with multiple processes executing its code. When
running on SMP, the exact same holds true, except now code execution is
truly concurrent. So the kernel runs on all processors. Various spinlocks
provide resource protection and mutual exclusion where needed, which means
sometimes one processor will have to spin its wheels waiting to access
something, but this is no different from NT.
But don't take my word for it, look at the source.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- 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/