On Fri, 25 Aug 2000, Jamie Lokier wrote:
>
> A stack page is _not_ required for a kernel thread, except when that
> thread is blocked. A sleeping but runnable task doesn't require a stack.
Wrong.
A stack page _is_ required for a thread, basically always:
- when it is running (either in user or kernel space): interrupts happen.
You can't share the stack page sanely with other processes, because the
interrupt can (and often does) cause a task-switch to another
completely unrelated process. And you have to save the register state
somewhere.
NOTE! Linux does NOT save the register state in the task struct. Saving
state in the task struct is a horrible waste of time when it has been
already saved on the stack for other reasons (ie the stack contains not
just the register state, but the instructions about how to unwind it
from recursive faults etc).
- when it is sleeping in kernel space: the stack contains the full path
to where it slept, we _need_ it.
Basically, the _only_ time you don't need a kernel stack is when the
process is completely idle, ie it has been scheduled away because its
time-slice ended, and it wasn't in kernel mode when this happened. And
Linux doesn't consider this a special state at all - as far as the kernel
is concerned, that sleeping state is the same as sleeping in kernel mode.
Quite frankly, the stack _is_ part of the "struct task_struct". It's not
just a performance optimization to allocate them together. Sure, the fact
that we allocate them together means one less allocation, and it allows
the clever "current" games we play with the stack pointer, but those are
details. Fundamentally, the two are part of the same thing.
Yes, you could do it differently. In fact, other OS's _do_ do it
differently. But take a look at our process timings (ignoring wild claims
by disgruntled SCO employees that can probably be filed under "L" for
"Lies, Outright"). Think about WHY our system call latency beats everybody
else on the planet. Think about WHY Linux is fast. It's because it's
designed right.
Continuations and other crap only add overhead. 8kB of storage for the
whole thread state (including the kernel stack) is _incredibly_ tiny.
> The alternative is user space lightweight threads which as we know can
> be very light indeed - comparable with procedure calls and event loops.
Indeed. They aren't real threads, though. The same way that DOS isn't
really a multi-tasking operating system, even if you can create an
environment on top of it that looked almost threaded.
Yes, you can get lower-latency threads. But they won't be the "real
thing". They won't scale on SMP, and they'll have other limitations too
(often they require synchronous task-switching, because that allows
optimizations like not saving the whole register state: which can be a BIG
win when the register state is big or slow to save like the x86 FP state).
Trust me. You won't find faster true threads than what Linux offers. And
they won't be using less than 8kB of memory.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:16 EST