Re: top stack (l)users for 2.5.69

[William Lee Irwin III <wli@holomorphy.com>]

On Wed, May 07, 2003 at 09:01:44AM -0700, William Lee Irwin III wrote:
>> Pure per-cpu stacks would require the interrupt model of programming to
>> be used, which is a design decision deep enough it's debatable whether
>> it's feasible to do conversions to or from at all, never mind desirable.
>> Basically every entry point into the kernel is treated as an interrupt,
>> and nothing can ever sleep or be scheduled in the kernel, but rather
>> only register callbacks to be run when the event waited for occurs.
>> Scheduling only happens as a decision of which userspace task to resume
>> when returning from the kernel to userspace, though one could envision
>> a priority queue discipline for processing the registered callbacks.

On Thu, May 08, 2003 at 05:36:47PM +0200, Ingo Oeser wrote:
> To illustrate that: It's basically a difference like between
> fork() and spawn(). Threads (of control) are completely decoupled
> und re-coupled only by the event/callback mechanism. 
> This is introducing exactly the mechanisms Linus didn't like when
> he decided, that he doesn't want a micro kernel architecture.
> So it is not going to happen RSN.

Your analogy is poor and I vaguely doubt the mechanism has been
suggested by anyone for use in Linux ever. It has nothing whatsoever to
do with a microkernel and in most incarnations precludes microkernel
designs. I'm not suggesting it, I just thought that was what "per-cpu
stacks" was supposed to mean.

Not that elaboration is needed, but the threads of control are not
decoupled as you suggest, but rather connected with continuations at
what would in the UNIX model be scheduling points. spawn() is just
POSIX' API for optimizing out some of the overhead of a fork()/exec()
cycle, and has nothing to do with interrupt model programming, esp.
since it is the exact opposite of thread creation. i.e. the interrupt
model is the extreme incarnation of "state machines, not threads".


-- wli