Linux Kernel: Threading vs Process - task_struct vs thread_info Linux Kernel: Threading vs Process - task_struct vs thread_info multithreading multithreading

Linux Kernel: Threading vs Process - task_struct vs thread_info


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.

  1. thread_info is architecture dependent. task_struct is generic.
  2. 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