I wonder whether or not a systems max kernel threads are determined by how many cores your CPU has. Or is it decided in another way?
Number of kernel threads = cores
kernel
Related Solutions
I can't definitively answer the "kernel threads" question for Linux. For Windows, I can tell you that the "kernel threads" are simply threads created from some other kernel mode routine, running procedures that never enter user mode. When the scheduler picks a thread for execution it resumes its previous state (user or kernel, whatever that was); the CPU doesn't need to "tell the difference". The thread executes in kernel mode because that's what it was doing the last time it was executing.
In Windows these typically are created with the so-called "System" process as their parent, but they can actually be created in any process. So, in Unix they can have a parent ID of zero? i.e. belonging to no process? This actually doesn't matter unless the thread tries to use process-level resources.
As for the addresses assigned by the compiler... There are a couple of possible ways to think about this. One part of it is that the compiler really doesn't pick addresses for much of anything; almost everything a compiler produces (in a modern environment) is in terms of offsets. A given local variable is at some offset from wherever the stack pointer will be when the routine is instantiated. (Note that stacks themselves are at dynamically assigned addresses, just like heap allocations are.) A routine entry point is at some offset from the start of the code section it's in. Etc.
The second part of the answer is that addresses, such as they are, are assigned by the linker, not the compiler. Which really just defers the question - how can it do this? By which I guess you mean, how does it know what addresses will be available at runtime? The answer is "practically all of them."
Remember that every process starts out as an almost completely blank slate, with a new instantiation of user mode address space. e.g. every process has its own instance of 0x10000. So aside from having to avoid a few things that are at well-known (to the linker, anyway) locations within each process on the platform, the linker is free to put things where it wants them within the process address space. It doesn't have to know or care where anything else already is.
The third part is that nearly everything (except those OS-defined things that are at well-known addresses) can be moved to different addresses at run time, due to Address Space Layout Randomization, which exists on both Windows and Linux (Linux released it first, in fact). So it doesn't actually matter where the linker put things.
This is due to a known bug in LXC regarding the cpuset
cgroup.
A few workarounds are described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824519 .
Best Answer
No, you can set the maximum kernel threads to very high numbers.
Note that the word "threads" is used for many different things:
Most programmers use it to refer to independent threads of execution in the sense of POSIX threads. This is a way of organising programs and does not depend on hardware support. See Maximum number of threads per process in Linux?
Intel use it to refer to their "Hyperthreading" technology. See Why does my Intel i7-920 display 8 cores instead of 4 cores? and What does "thread" mean as related to CPUs?
It may be that Intels use causes confusion.
Update re kernel threads
Here are some Linux kernel threads running in CoLinux under Vista on AMD Athlon 64 X2 dual-core.
LWP is the thread ID.
(See
man ps
: "-L Show threads, possibly with LWP and NLWP columns" … "LWP lwp (light weight process, or thread) ID of the lwp being reported. (alias spid, tid)")kthreadd is the kernel thread daemon, I believe is is responsible for all the other kernel threads. Note I am not showing daemons like klogd which do not execute in ring 0 (as far as I know).
Number of kernel threads != number of CPU cores. (ref title of question)
…
…
…
(Multiple Flows of Control in Migratable Parallel Programs 2006)