Messages in this thread |  | | | Date | Fri, 25 Aug 2000 09:48:48 -0700 (PDT) | | From | Linus Torvalds <> | | Subject | Re: SCO: "thread creation is about a thousand times faster than onnative |
| |
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/
|  |