Linux Kernel: Threading vs Process - task_struct vs thread_info

Question

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.

Answer 1

Linux supports threads.

Threads are similar to processes, but whereas each process has its own address space (stack, heap, program code), threads share the address space and therefore can each access the heap data. Since the address space is shared then during the context switch we don't need to switch which page table we are using to convert virtual memory to physical memory. Since two threads access the same address space in a multi-threaded application you would have multiple stack areas, one for each thread.

Yes, process's state is stored in a task_struct as state. You can explore what is stored in a task_struct by going to the sched.h file.

Threads and processes are very similar, but sometimes you want to share the data i.e. when you operate on a large data set (add two large arrays etc).

Answer 2

The task_struct is a large data structure. Hence the task of storing large structure is very much difficult. So kernel introduced concept of thread_info , which is very much slimmer than task_struct and just points to task_struct structure.

Source

Answer 3

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

Answer 4

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.

Answer 5

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.