I read that Linux does not support the concept of threads or light-weight processes and that it considers kernel threads just like any other process. However this principle is not very accurately reflected inside the code. We see task_struct that holds state information of a process (correct me if wrong) and also thread_info appended to the bottom of a process' kernel stack.
Now the question is why does the code support the concept of individual threading through thread_info when linux is supposed to interpret threads like any other process?
Please let me know what I am missing here - I am a newbie to linux kernel dev.
Threads in Linux are treated as processes that just happen to share some resources. Each thread has its own thread_info (at the bottom of the stack like you said) and its own task_struct. I can think of two reasons why they are maintained as separate structures.
thread_info is architecture dependent. task_struct is generic.thread_info cuts into the size of the kernel stack for that process, so it should be kept small. thread_info is placed at the bottom of the stack as a micro-optimization that makes it possible to compute its address from the current stack pointer by rounding down by the stack size saving a CPU register.Older approach: In the older kernel, prior to 2.6, process descriptors were allocated statically, hence it was possible to read the value from a particular offset from this struct.
New approach: But in 2.6 and later version, you could allocate process descriptors dynamically using slab allocator. Hence, the older approach no longer worked. Hence Thread_info was introduced .
It is mentioned clearly in the book Linux Kernel Development, Chapter 3:
The task_struct structure is allocated via the slab allocator to provide object reuse and cache coloring (see Chapter 11, "Memory Management"). Prior to the 2.6 kernel series, struct task_struct was stored at the end of the kernel stack of each process. This allowed architectures with few registers, such as x86, to calculate the location of the process descriptor via the stack pointer without using an extra register to store the location. With the process descriptor now dynamically created via the slab allocator, a new structure, struct thread_info, was created that again lives at the bottom of the stack (for stacks that grow down) and at the top of the stack (for stacks that grow up)[4]. See Figure 3.2. The new structure also makes it rather easy to calculate offsets of its values for use in assembly code.
As Peter said, thread_info is architecture specific which contains necessary information such as registers, pc, fp etc.
This information is required for saving/restoring the process execution during context switch.
http://lxr.free-electrons.com/source/arch/arm/include/asm/thread_info.h#L33
task_struct --> thread_info --> struct cpu_context_save cpu_context