<![CDATA[Linux Kernel]]>https://linux-kernel.hashnode.devRSS for NodeFri, 18 Sep 2026 01:20:04 GMT60<![CDATA[Memory Management]]>https://linux-kernel.hashnode.dev/memory-managementhttps://linux-kernel.hashnode.dev/memory-managementWed, 03 Dec 2025 03:22:45 GMTPage Cache

A part of the disk is maintained in physical RAM known as Page Cache. This cache is used to improve the performance of the system. A read or write from the physical memory is faster than from the disk.

The page cache consists of actual physical pages in RAM(not virtual), the contents of which correspond to the blocks on a disk. The size of this cache can grow dynamically, increases if more memory is available or shrinks for any memory pressure.

Whenever a read() call is performed by the process, the data is read from the Page cache. If required pages are found, then its called a cache-hit, otherwise its a cache-miss, during which block I/O operations are performed and the data is copied from the disk to the cache and read again.

When the process does a write() call, there are three strategies available.

  • A write() operation directly writes data to the disk. This strategy is called no-write, as shown below. If the data need to be read, it needs to be fetched into the cache first and then perform a read operation. This is not efficient strategy and is rarely used.

  • In the second strategy, the data is written to both the cache and the disk. This way, a further read operation will get a cache-hit. Though this is good, the overall time to copy to the disk undermines having a cache in the first place.

  • In the third case, data is written to the cache first. The backing store is not updated yet. Instead, the written to pages are marked as dirty and are added to the dirty list. Periodically, dirty pages are written back to the disk in a process called writeback, bringing the on-disk copy in line with the on-cache copy. The pages are no longer dirty after this happens. This strategy is used in Linux.

]]><![CDATA[Process Management]]>https://linux-kernel.hashnode.dev/process-managementhttps://linux-kernel.hashnode.dev/process-managementThu, 20 Nov 2025 01:24:50 GMTThis blog will discuss process creation and termination from the programmer’s point of view.

Process creation

Init is the first process that gets spawned during the boot process and this process gets process Id 1. All the other processes are created using a system call called, fork().

The process which calls the fork is called the parent process and the process which gets created as a result of the fork call is called a child process. A child process will get the parent process Id (PPID) that of the parent process which created it.

A new task_struct data structure gets created, every time a new process gets created. The memory requirements are handled by the SLAB cache.

💡
task_struct has been discussed in another blog here.

Let’s see how a process is created.

  • A parent process calls fork() system call.

  • The fork() call is intercepted in ‘./kernel/fork.c’ and calls kernel_clone(). The later takes a parameter called flags. Flags help decide which resources can be shared between the child and the parent process.

flags have been explained later in this blog.

  • In kernel_clone(), a call to copy_process() creates a new process( say p), but not activated or scheduled yet. This step involves copying the relevant resources as per the flags defined.

  • Process ‘p’ is scheduled and it starts running.

Different flags that decide how the child process will be created as below:

CLONE_VMParent and Child share address space
CLONE_FILESParent and Child share open files
CLONE_FSParent and Child share file system information
CLONE_SIGHANDParent and Child share the signal handlers and blocked signals
CLONE_PIDFDIf pidfd of the child should be placed in the parent process
CLONE_PTRACEContinue tracing the child too
CLONE_VFORKUsed when vfork() is used instead of the fork(). Parent process will be forced to sleep until the child process returns
CLONE_PARENTChild enforces to have the same parent which created it
CLONE_THREADParent and child are in the same thread group
CLONE_NEWNSCreate a new namespace for the child process
CLONE_SYSVSEMParent and child share the system-V semantics
CLONE_SETTLSCreate a new TLS for the child process
CLONE_PARENT_SETTIDSet the TID in the parent
CLONE_CHILD_CLEARTIDClear the TID in the child
CLONE_CHILD_SETTIDSet the TID of the child
CLONE_DETACHEDDetach and ignore the child process
CLONE_UNTRACEDIgnore the CLONE_PTRACE on the child
CLONE_NEWCGROUPCreate a new cgroup namespace
CLONE_NEWUTSCreate a new utsname namespace
CLONE_NEWIPCCreate a new ipc namespace
CLONE_NEWUSERCreate a new user namespace
CLONE_NEWPIDCreate a new pid namespace
CLONE_NEWNETCreate a new network namespace
CLONE_IOClone the IO context

copy_process()

  • Make a call to dup_task_struct(), which creates a new kernel stack, thread_info and task_struct structure for the new process. The new values are identical to those of the current task. At this point, the child and parent process descriptors are identical.

  • It then checks that the new child will not exceed the resource limits on the number of processes for the current user.

  • The child needs to differentiate itself from the parent. Various members of the process descriptor are cleared or set to initial values. Members of the process descriptor not inherited are primarily statistically information. The bulk of the values in task_struct remain unchanged.

  • The child’s state is set to TASK_UNINTERRUPTIBLE to ensure that it does not yet run.

  • copy_process() calls copy_flags() to update the flags member of he task_struct.

  • It calls alloc_pid() to assign an available PID to the new task.

  • Depending on the flags passed to kernel_clone(), copy_process() either duplicates or shares open files, filesystem information, signal handlers, process address space and namespace. These resources are typically shared between threads in the same process, otherwise they are unique and thus copied here.

  • Finally, copy_process() cleans up and returns to the caller a pointer to the new child.

Process states

Each process goes through the below states, through its life time.

  • When the process gets created, it gets the TASK_RUNNING(ready) status. In this state, the process is ready to be run by the scheduler.

  • Once the scheduler puts the process to run, its state is moved to TASK_RUNNING(running) status.

  • When the process is pre-emptied by the scheduler for another higher priority one, it moves back from TASK_RUNNING(running) to TASK_RUNNING(ready) state.

  • When a process waits for any event(like IO), its moved to TASK_INTERRUPTABLE(waiting) state.

  • When the event is full-filled, the process is moved back to TASK_RUNNING(ready) state.

  • When a process calls exit() or receives any signal or exception, it is moved to TASK_STOPPPED state and is terminated.

Process address space

Linux is a virtual memory operating system, meaning the physical memory is virtualized for each process. Meaning, each process’s view of memory is as if it has the entire physical memory to access.

The process address space consists of the virtual memory addressable by a process and the address within the virtual memory that the process is allowed to use. Each process is given a flat 32-bit or 64-bit address space, with the size dependent on the architecture.

A memory address is a given value in the given address space, 0X5012E300. This value identifies a byte in a process’s 32-bit address space. A process address applicable for a particular process can be represented as a range, for ex, 0X0400A000 - 0X0400AFFF. These intervals are usually called memory areas. The process, through the kernel, can add or remove memory areas to its address space.

Each memory area is associated with permissions like readable, writable and executable.If a process accesses any address which it doesn’t have permission to, it results in segmentation fault.

Each process is associated with the below memory areas:

  • A memory map of the executable file’s code, called a text section.

  • A memory map of the executable file’s initialized global variables, called the data section.

  • A memory map of the executable file’s uninitialized global variables, called the bss section.

  • A memory map for the process’s user space stack.

  • An additional text, data and bss section for each of the shared library( such as glibc, dynamic linker etc) loaded into the process’s address space.

  • Any memory mapped files.

  • Any shared memory segments(ipc related).

  • Any anonymous memory mappings, such as those associated with malloc().

Virtual memory areas

Each of the color coded segment in the above process address space is called a virtual memory area(VMA). This is represented by a data structure called vm_area_struct, which is defined in the file ./linux/mm_types.h.

The above process address space may look like below with VMAs

Programmatically, each process is represented by a data structure of type ‘struct task_struct’. This data structure has a field called ‘struct mm_struct’ which maintains a linked list of type ‘struct vm_area_struct’.

Each of the VMA has a start address (vm_start) and ending address(vm_end). All the address ranges being held by the process are virtual in nature. We will learn later that each of the VMA points to the physical memory through pages.

System calls like mmap(), mmap2(), do_mmap() can be used to add VMAs. System calls like munmap() and do_munmap() can be used to remove them.

More about memory management will be covered in another blog

Process address space in real life…

Let’s create some simple and sample programs and check practically how the process address space looks like by running some commands.

Commands
We can use commands like ‘pmap <pid>’ or ‘cat /proc/<pid>/maps’ to read the process address map of a process. The first command gives a more user friendly output. We can use these commands only when the process is running.

  1. A program with no global, static or local variables. I am using C but the program language shouldn’t matter.

     #include<unistd.h>

 int main(int argc, char *argv[]) { 
   # without this sleep() command, the process doesnt persists for 
   # enough time to get the details
   sleep(100);
   return 0;
 }

The process address space is as below. The memory range may be different each time. Also, the memory ranges may not be contiguous, as the kernel assigns the memory as per the availability.

Let’s try to understand what each of the above attributes mean:

  • [vdso]: Virtual Dynamically Linked Shared Objects. This is a mechanism through which the interaction between the user space and kernel space is optimized for better performance.

  • [vsyscall]: This is a static allocation (each process uses the same vma), used to optimize the system call performance. The output of the system call is stored here for future reference. Very similar to cache used in other places.

  • [vvar]: Not much information is available about this vma.

  • [stack]: This vma is the user space stack. We have read and write permissions on this vma.

  • [ anon ]: vma for anonymous memory. This memory is usually assigned to the process by the kernel which is not backed by a file on the file system. Mostly for internal purposes.

  • [libc.so.6]: This is the C library(glibc), which is required to interpret the code.There are 5 entries, as below:

    • r——: This is a vma of type ‘rodata’(read only) for the C library(libc.so.6)

    • r-x—: This is a vma with read and execute permissions, meaning this hold the actual code of text of libc.so.6

    • r——: Another ‘rodata’ vma

    • r——: Another ‘rodata’ vma

    • rw—-: A read and write vma(rwdata) for the variables which allows reads and writes.

  • [ld-linux-x86-64.so.2]: This is a dynamic linker which is required to link the code with other shared libraries. We have similar ‘rodata ‘and ‘rwdata’ vmas for this library, similar to glibc.

  • [p1]: This is my actual C code file name. Kernel has assigned 5 vma’s for this code too, similar to above entries.

As you might have noted, a minimum of 4K has been assigned for each vma. This is the page size on my machine. All the memory assignments are in multiples of this pagesize.

Also, a total of 2616K (2.6 MB) has been assigned even to a simple program like this.

  1. Process address map for all the below scenarios were same as above.

    • A program with an uninitialized global variable.

    • A program with initialized or uninitialized local variables.

    • A program with static variables.

This means that the kernel assigns a minimum of one page size memory to each vma irrespective of whether the program needs it or not.

  1. A program makes a call to malloc() for dynamic memory allocation.

     #include<unistd.h>
 #include<cstdlib>
 #include<cstring>

 struct emp_det {
         long emp_id;
         char name[100];
 };

 int main(int argc, char *argv[]) {
   struct emp_det* ep = (struct emp_det *)malloc(sizeof(struct emp_det));
   ep->emp_id = 1234;
   strcpy(ep->name, "citika");

   sleep(100);
   return 0;
 }

The process address space in this case as shown below:

As you can see, there is an extra 132K of memory assignment to a [heap] region. This is for the dynamic allotments for the call to malloc().

  1. Two processes which are running the same code.

    Both the process address maps look similar. Also, note that though they use the same glibc and linker’s, they are mapped to different vmas. This is an interesting finding, as the expectation was all the processes which use the same shared libraries point to the same memory areas.

  2. A child process created using the fork() system call. The goal is to check the process memory space for both the child and parent.

     #include <stdio.h>
 #include <unistd.h>
 #include <sys/types.h>
 #include <sys/wait.h>

 int main() {
     pid_t pid = fork();

     if (pid < 0) {
         // fork() failed
         perror("fork failed");
         return 1;
     }
     else if (pid == 0) {
         // Child process
         printf("Child process: PID = %d, Parent PID = %d\n",
                getpid(), getppid());

         // Simulate some work
         sleep(100);

         printf("Child exiting...\n");
     }
     else {
         // Parent process
         printf("Parent process: PID = %d, waiting for child PID = %d\n",
                getpid(), pid);

         int status;
         wait(&status);   // Wait for child to finish

         printf("Parent: child exited with status %d\n", WEXITSTATUS(status));
     }

     return 0;
 }

    Process address map of the parent is:

    Process address map of the child is:

    As you see, the parent and child are sharing the same process address space.

    This is as per the design technique called Copy-On-Write(CoW) in which the kernel delays assigning the child to new address space until it is required. In this case, child process was not doing anything and hence was sharing the parent address space. This technique allows faster process execution.

  3. Let’s see a case where a child process is created and executes a new program. Here we are making the child process run ‘ls’ program.

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>

int main() {
    pid_t pid = fork();

    if (pid < 0) {
        perror("fork failed");
        return 1;
    }
    else if (pid == 0) {
        // Child process
        printf("Child: PID = %d, Parent PID = %d\n", getpid(), getppid());
        printf("Child: sleeping for 100 seconds inside exec...\n");

        // exec: run "sleep 100; ls -l"
        execl("/bin/sh", "sh", "-c", "sleep 100; ls -l", NULL);

        // Only reached if exec fails
        perror("exec failed");
        return 1;
    }
    else {
        // Parent process
        printf("Parent: PID = %d, Child PID = %d\n", getpid(), pid);
        printf("Parent: waiting for child to finish...\n");

        int status;
        wait(&status);

        printf("Parent: child exited with status %d\n", WEXITSTATUS(status));
    }

    return 0;
}

The parent process address map is as shown below:

The child process address map is as shown below:

As you can see, both parent and child are using different process address spaces.

Again, its CoW feature working behind the scenes.

Process Termination

A Process is terminated in the below ways:

  • A voluntary termination when the process calls exit() call or just a ‘return’ statement.

  • An involuntary termination happens when the process receives a signal or exception which it cannot handle or ignore.

When a process exits, a series of actions happen, which might be the reverse of the actions during the process creation. Process runs do_exit() call which takes care of the process termination.

  • Set the PF_EXITING flag in the flags member of task_struct.

  • Call del_timer_sync() to remove any kernel timers, which might have been activated for this process.

  • Flush out the accounting information, when it is set.

  • Calls the exit_mm() to release the mm_struct held by the process. If no other process is using this address space, then release the memory from the slab cache.

  • Calls exit_sem(), to release any IPC related semaphore’s from the waiting queues.

  • Calls exit_files() and exit_fs() to decrement the usage count of the objects related to file descriptors and file system data. If this count is zero, then remove the entries from the slab cache too.

  • Set the exit_code in the task_struct construct as volunteered by the exit process.

  • Calls exit_notify() to send signals to the parent process. This process children are de-parented to any other process in the same thread group or to the init process. The exit_state in the task_struct is set to EXIT_ZOMBIE.

  • Send communication to the scheduler to schedule another process. This happens as the final step in the do_exit() and this call never returns.

At this stage, the process is not in runnable state and doesn’t have any process address space of its own and is in EXIT_ZOMBIE state. The only memory associated is with the task_struct, thread_info in the slab cache. This memory exists so that the parent process can claim some information out of it. Once this is completed, the slab cache is freed too.

A process becomes zombie, when its parent tries to clear the process table of the dead child(alive parent and dead child).

A process becomes orphan when its parent is dead and is being re-parented(dead parent and alive child).

]]><![CDATA[Data structures in Linux kernel]]>https://linux-kernel.hashnode.dev/data-structures-in-linux-kernelhttps://linux-kernel.hashnode.dev/data-structures-in-linux-kernelMon, 27 Oct 2025 18:00:45 GMTstruct task_struct:

For every process that is created in the user space, kernel creates and maintains a data structure of type ‘struct task_struct’. This structure has all the information that the kernel needs to perform process management, scheduler management, memory management etc on this process. This data structure is stored in the kernel stack and is active as long as the process is alive. This structure is defined in <linux/sched.h>

Below is the list of attributes this structure holds and the purpose of each attribute.

sl no

Attribute name

Attribute type

Config setting needed

Attribute Usage

1

thread_info

struct thread_info

CONFIG_THREAD_INFO_IN_TASK

Used for storing low level CPU information related to threads belonging to the process. Mainly it provides information on which CPU the thread is running, CPU conext and CPU flags used for the threads

2

state

unsigned int

Store the process state, like TASK_RUNNABLE, TASK_INTERRUPTABLE etc

3

saved_state

unsigned int

This state refers to the status of trying to acquire a spinlock, common in multi-threaded applications. If lock acquisition fails, the thread is put to sleep and this state is preserved as "sleeping". It has nothing to do with the _state of the process.

4

stack

void

Refers to the tasks kernel-stack. Usually used to get the thread_info from a variable of type struct task_struct, as in the macro: #define task_thread_info(task) ((struct thread_info )(task)->stack)

5

usage

refcount_t

Used to count the number of references to the process(users)

6

flags

unsigned int

various flags used by the process for varous purposes.

7

ptrace

unsigned int

Holds the flags related to ptrace status of a process

8

alloc_tag

struct alloc_tag

CONFIG_MEM_ALLOC_PROFILING

used to track the memory allocations by the kernel

9

on_cpu

int

Serves as a lock mechanism for dealing with context switching b/w processes. When on_cpu is 0,it means this process is not running on any CPU and can be scheduled to run on any other CPUs. If set to any other value, this information helps in proper migration of the process across CPUs and avoid data inconsistencies.

10

wake_entry

struct call_single_node

This entry plays a role in how the scheduler wakes the processes to be scheduled, in the SMP environments.

11

wakee_flips

unsigned int

Helps the scheduler to track and make decisions about where to schedule based on previous wakeup patterns

12

wakee_flip_decay_ts

unsigned long

13

last_wakee

struct task_struct

14

recent_used_cpu

int

Recently used CPU by a process. Usually used for re-schedule on the same CPU if found idle.

15

wake_cpu

int

Represents the CPU where the process is intended to be woken up or woke up last

16

on_rq

int

Indicates the presence of a process on a run queue. Each CPU has its own run queue.
Can take two values:
1.TASK_ON_RQ_QUEUED : Process is on a CPU running queue.
2. TASK_ON_RQ_MIGRATING: Process is being moved from one running queue to another.

This attribute helps with synchronisation of the processes on the running queues and helps with scheduling.

17

prio

int

This field is used by the scheduled to decide which process should be scheduled next. This value can be adjusted by the kernel dynamically or is based on 'nice' values.

18

static_prio

int

This value represents the nice value of the process which can be set by the users. This value cannot be dynamically adjusted by the kernel like 'prio'

19

normal_prio

int

This field is the default priority calculated based on the static_prio and real-time priority. This is important in fork() where the child process prio is set to the normal_prio of the parent.

20

rt_priority

unsigned int

This field is used for managing the real-time processes, usually used in embedded systems. This field is used by real-time scheduling algorithms like SCHED_FIFO, SCHED_RR. This value can be set by system calls.

21

se

struct sched_entity

This represents the scheduling entity used by the default Linux scheduler CFS(Completely Fair Scheduler)

22

rt

struct sched_rt_entity

This represents the scheduling entity used by the Real-Time scheduler classes like SCHED_FIFO and SCHED_RR

23

dl

struct sched_dl_entity

These represents the scheduling entity used by the Earliest Deadline First scheduler like SCHED_DEADLINE

24

dl_server

struct sched_dl_entity

25

scx

struct sched_ext_entity

CONFIG_SCHED_CLASS_EXT

This entry represents the scheduling class called sched_ext(called SCX)

26

sched_class

struct sched_class

This represents the scheduling class used by the process such as CFS, RT, DL etc

27

core_node

struct rb_node

CONFIG_SCHED_CORE

This field is used in the implementation of the control groups feature(cgroups). This field is controlled by CONFIG_SCHED_CORE setting

28

core_cookie

unsigned long

This field relates to core scheduler, a mechanism where all the related processes are made to schedule on the same physical CPU to improve performance. Each of these processes have the same ‘core_cookie’ value. Based on this value, the process's scheduling is optimized by the core scheduler. This field is controlled by CONFIG_SCHED_CORE setting.

29

core_occupation

unsigned int

This field is controlled by CONFIG_SCHED_CORE setting. Not much information is available why this is used for.

30

sched_task_group

struct task_group

CONFIG_CGROUP_SCHED

This field is used to categorize processes into a cgroup hierarchy.

31

uclamp_req

struct uclamp_se

CONFIG_UCLAMP_TASK

These fields allow the user to specify the min and max utilization allowed for RUNNABLE processes.

32

uclamp

struct uclamp_se

CONFIG_UCLAMP_TASK

33

stats

struct sched_statistics

This field is used to collect and track the performance metrics of the scheduler. Some of the metrics involved are execution times, number of context switches etc

34

preempt_notifiers

struct hlist_head

CONFIG_PREEMPT_NOTIFIERS

This field provides a mechanism to register callbacks that are executed whenever the process is pre-emptied or re-scheduled.

35

btrace_seq

unsigned int

CONFIG_BLK_DEV_IO_TRACE

This field helps track the block I/O requests for this process

36

policy

unsigned int

This field determines scheduling policy like SCHED_FIFO, SCHED_RR etc. Looks like a duplicated effort, we have other fields like ece, rt, dl, dl_serve which do the same thing

37

max_allowed_capacity

unsigned long

This field represents how much of CPU capacity a process is allowed to consume. Again looks like a duplicated effort.

38

nr_cpus_allowed

int

This field represents the number of CPUs a process is allowed to run on

39

cpus_ptr

const cpumask_t

This field points to a pointer of type cpumask_t, which represents number of CPUs a process is allowed to run on, duplicates the earlier nr_cpus_allowed field

40

user_cpus_ptr

cpumask_t

This field points to the cpumask_t pointer specifically requested by a user for a particular process

41

cpus_mask

cpumask_t

Again this field represents a variable of type cpumask_t which provides the CPU affinity of a process

42

migration_pending

void

This field is an indicator to represent that this process is waiting for a pending migration to a different CPU

43

migration_disabled

unsigned short

This field indicates if a migration is possible across CPUs

44

migration_flags

unsigned short

This field is used to control and track the migration effort within the system

45

rcu_read_lock_nesting

int

CONFIG_PREEMPT_RCU

RCU stands for Read-Copy Update, a mechanism used to synchronize data structures shared across threads within a process. This field is a counter to represent the read-side critical sections of a thread.

46

rcu_read_unlock_special

union rcu_special

CONFIG_PREEMPT_RCU

This field represents the state when the thread is in read-side critical section.

47

rcu_node_entry

struct list_head

CONFIG_PREEMPT_RCU

All the threads, which are in RCU read-side critical sections are added to a list. This field rcu_node_entry acts as the head of that list.

48

rcu_blocked_node

struct rcu_node

CONFIG_PREEMPT_RCU

This field is not NULL If the present thread is blocking the RCU read-side critical section, otherwise NULL

49

rcu_tasks_nvcsw

unsigned long

CONFIG_TASKS_RCU

This field tracks the voluntary context switches undergone by a thread. This parameter is useful in implementing the RCU mechanism

50

rcu_tasks_holdout

u8

CONFIG_TASKS_RCU

This field acts as a signal for the RCU subsystem, that a particular thread, needs to finish on the RCU read-side critical sections before the end of the grace period allotted.

51

rcu_tasks_idx

u8

CONFIG_TASKS_RCU

This field helps to understand if the thread, is in the RCU read-side critical section of exited it, for tracking purposes.

52

rcu_tasks_idle_cpu

int

CONFIG_TASKS_RCU

This field tracks on which CPU a particular idle task is executing on.

53

rcu_tasks_holdout_list

struct list_head

CONFIG_TASKS_RCU

This field is a list head which represents the list of threads that are currently being holding out on the grace period.

54

rcu_tasks_exit_cpu

int

CONFIG_TASKS_RCU

This field tracks the threads, that are exiting a RCU grace period.

55

rcu_tasks_exit_list

struct list_head

CONFIG_TASKS_RCU

This field is a list which is used to track the threads, which are exiting the RCU read-side critical sections.

56

trc_reader_nesting

int

CONFIG_TASKS_TRACE_RCU

This field is a counter to track the threads passing in and out of the RCU critical regions. Used for tracking purposes.

57

trc_ipi_to_cpu

int

CONFIG_TASKS_TRACE_RCU

IPI stands for Inter-Processor Interrupts. These are interrupts used by a CPU to interrupt another CPU. This field is used to store the CPU id that needs to be interrupted

58

trc_reader_special

union rcu_special

CONFIG_TASKS_TRACE_RCU

This field is used for handling and tracking purposes by threads in the RCU system which act as RCU readers

59

trc_holdout_list

struct list_head

CONFIG_TASKS_TRACE_RCU

This field is a list head which represents the list of threads that are currently being holding out on the grace period.

60

trc_blkd_node

struct list_head

CONFIG_TASKS_TRACE_RCU

This list represent the list which holds information on all the threads which are waiting for the RCU grace period to be completed so that they can perform an update operation

61

trc_blkd_cpu

int

CONFIG_TASKS_TRACE_RCU

This field holds the CPU information on which the RCU operations have been blocked

62

sched_info

struct shed_info

This field holds scheduler information like how many times this process has been run on a particular CPU, amount of time spent in a run queue etc

63

tasks

struct list_head

There is no much information about this field but could be holding information all the process in the system

64

pushable_tasks

struct plist_node

This field represents the list of tasks which can be pushed to other runqueues, which are not so busy

65

pushable_dl_tasks

struct rb_node

This field represents the tasks which are ready to be scheduled by the deadline scheduler.

66

mm

struct mm_struct

This field represents the entire virtual address space allocated for this process

67

active_mm

struct mm_struct

This field represents the currently active part of the memory address space. Usually used by kernel threads as 'mm' field is NULL for them.

68

faults_disabled_mapping

struct address_space

This field acts as a temporary marker that tells that the page faults for a particular memory region should be handled in a special way

69

exit_state

int

This field is used to store the exit state of a process. It can take two values:
1. EXIT_ZOMBIE: Indicates that the process is done with its execution but the resources are not freed yet. This happens when the child process exited but the parent process didn't call wait() yet.
2. EXIT_DEAD: Indicates that the process is done with its execution and its resources have been freed too. Happens immediately after the parent process calls the wait4() call on a zombie process.

70

exit_code

int

This field stores the exit status of a process. Usually its zero(0) when exited successfully and non-zero if not.

71

exit_signal

int

This field is usually the signal sent to the parent process when a child process is dead. Usually this is SIGCHLD

72

pdeath_signal

int

This field indicates the signal sent when a parent process dies

73

jobctl

unsigned long

This field is used to process the job control flags for a process or thread

74

personality

unsigned int

This field represents the execution domain of a process. The way some system calls behave differently for a process are based on this information

75

sched_reset_on_fork

unsigned

This is a flag used by the parent process to control the inheritance of privileged scheduling mechanisms by the child processed, acquired through the fork() process. Used mostly for security purposes.

76

sched_contributes_to_load

unsigned

When this flag is set, this processes system load is included in the load average calculation

77

sched_migrated

unsigned

This flag is set when a process is migrated from one CPU to the another. Helps the scheduler to track the process location and manage its scheduling on the new CPU

78

sched_task_hot

unsigned

When a process frequently uses data that resides in a particular CPU cache, its considered "cache hot" for that CPU. Moving such a process to a different CPU can lead to performance degration as the data needs to be re-loaded for that CPU. If this flag is set, it can work as a strong affinity for that CPU. A scheduler might hesitate to migrate such a process from that CPU for performance issues.

79

sched_remote_wakeup

unsigned

This field acts as a flag to indicate if the process has been remotely woken up by another CPU

80

sched_rt_mutex

unsigned

CONFIG_RT_MUTEXES

When a real-time process acquires an RT mutex, this flag is set to 1, indicating that this process is in the middle of the critical section. This is an indicator to the scheduler to handle it accordingly.

81

in_execve

unsigned

This field indicates if the process is in the middle of an execve() call

82

in_iowait

unsigned

This field indicates if the process is waiting on an I/O activity

83

restore_sigmask

unsigned

TIF_RESTORE_SIGMASK

This field indicates if the process sigmask needs to be reset after handling a signal handler

84

in_user_fault

unsigned

CONFIG_MEMCG_V1

This field indicates if the process is handling a user-space page fault

85

in_lru_fault

unsigned

CONFIG_LRU_GEN

This field indicates if the process is handling a page fault that involves LRU page replacement system

86

brk_randomized

unsigned

CONFIG_COMPAT_BRK

This field indicates if the heap area of the process is randomized(starts at a different address), for security purposes

87

no_cgroup_migration

unsigned

CONFIG_CGROUPS

When this field is set to 1, then it indicates that this process cannot be moved to a different cgroup.

88

frozen

unsigned

CONFIG_CGROUPS

This flag indicates if the process is immune to system wide freezing

89

use_memdelay

unsigned

CONFIG_BLK_CGROUP

Usually used in allowing a memory delay for disk I/O throttling operations

90

in_memstall

unsigned

CONFIG_PSI

This field is used to indicate if the process is stalled due to non-availability of the system resources, especially memory

91

in_page_owner

unsigned

CONFIG_PAGE_OWNER

This field is used to avoid recursion while page tracking

92

in_eventfd

unsigned

CONFIG_EVENTFD

This field indicates if the process is currently in the execution context of the eventfd_signal() function

93

pasid_activated

unsigned

CONFIG_ARCH_HAS_CPU_PASID

This field indicates if the Process Address Space Id (PAS ID) has been activated for this process

94

reported_split_lock

unsigned

CONFIG_X86_BUS_LOCK_DETECT

This field is used to indicate if a split lock has been detected for the process

95

in_thrashing

unsigned

CONFIG_TASK_DELAY_ACCT

Thrashing usually indicates the situation where the kernel spends more time swapping the data between physical memory and secondary disk than doing some useful work. This field is set to indicate that this process is experiencing thrashing like behavior.

96

in_nf_duplicate

unsigned

This field indicates that the process is currently involved in Netfilter packet duplication operations.

97

net_xmit

struct netdev_xmit

CONFIG_PREEMPT_RT

This field helps in managing aspects of network transmission related to the process.

98

atomic_flags

unsigned long

This field has list of flags related to a process or thread that need to be modified and read in an atomic manner

99

restart_block

struct restart_block

This field is used to define the restart behavior of the system calls.

100

pid

pid_t

Unique id of the process

101

tgid

pid_t

Pocess id of the Thread Group leader

102

stack_canary

unsigned long

CONFIG_STACKPROTECTOR

This field is used as a security measure to deal with the stack buffer overflow attacks

103

real_parent

struct task_struct

This field is a pointer to the parent process

104

parent

struct task_struct

This field is a pointer to the parent which is supposed to receive the SIGCHLD signal

105

children

struct list_head

This field is a list of children created through the fork mechanism

106

sibling

struct list_head

This field is a list of siblings which have been created through the fork mechanism of which this process is a part of

107

group_leader

struct task_struct

This field is a pointer to the primary thread within a thread group

108

ptraced

struct list_head

This field is a list of process on which this process has put a ptrace on

109

ptrace_entry

struct list_head

This field is a pointer to the entry of this process's parent ptraced entries

110

thread_pid

struct pid

This fieldis is a pointer to the process pid structure

111

pid_links

struct hlist_node

This field is an array of size PIDTYPE_MAX(whose value is 4) of type struct hlist_nodes

112

thread_node

struct list_head

This field connects all the threads belongign to the same thread group

113

vfork_done

struct completion

This field is used to synchronize between parent and child process when vfork is used

114

set_child_tid

int

This field is to set the tid of child process ot thread when using the clone() system call

115

clear_child_tid

int

This field is used to wakeup the processes when a thread is terminated

116

worker_private

void

Thsi field is a pointer to the struct kthread when the process creates kernel threads using the kthread interface.

117

utime

u64

This field is the amount of CPU time the process has spent executing in the user space

118

stime

u64

This field is the amount of CPU time the process has spent executing in the kernel space

119

utimescaled

u64

CONFIG_ARCH_HAS_SCALED_CPUTIME

This field implies that the raw time value might be adjusted based on factors like CPU frequency scaling or other system level considerations

120

stimescaled

u64

CONFIG_ARCH_HAS_SCALED_CPUTIME

121

gtime

u64

This field is the total CPU time spent by all the threads in a proces group

122

prev_cputime

struct prev_cputime

This field is a struct which contains utime and stime as members. Looks like a duplicated effort.

123

vtime

struct vtime

CONFIG_VIRT_CPU_ACCOUNTING_GEN

Thsi field tracks the virtual time a process spends in kernel, mostly not when consuming the CPU time, but waiting for some events to happen, like waiting on I/O events

124

tick_dep_mask

atomic_t

CONFIG_NO_HZ_FULL

This field helps the kernel determine whether a CPU needs to maintain a timer tick or if it can safely go into a tickless idle state, to improve power efficiency

125

nvcsw

unsigned long

This field is a counter of voluntary context switches. Happens when a process or thread voluntariliy relinquishes the CPU while waiting for I/O activity etc

126

nivcsw

unsigned long

This field is a counter of involuntary context switches, happens when a process is preemptied by the kernel

127

start_time

u64

This field represents the process creation time, based on a monotonic clock, which never goes backwards

128

start_boottime

u64

This field represents the process creation time, relative to the system boot time. Usually used by 'ps' and 'top' commands to display the process creation time.

129

min_flt

unsigned long

This field is a counter for the minor page faults experienced by the process

130

maj_flt

unsigned long

This field is a counter for the major page faults experienced by the process

131

posix_cputimers

struct posix_cputimers

CONFIG_POSIX_CPUTIMERS

This field holds all the POSIX CPU timers like CPUCLOCK_PROF, CPUCLOCK_VIRT, CPUCLOCK_SHED etc

132

posix_cputimers_work

struct posix_cputimers_work

CONFIG_POSIX_CPU_TIMERS_TASK_WORK

Thie field helps mange the work related to the CPU timers for the process or thread

133

ptracer_cred

struct cred

This field is a data structure which encapsulates all the securty related credentials of the process or thread

134

real_cred

struct cred

135

cred

struct cred

136

cashed_requested_key

struct key

CONFIG_KEYS

This field points to a structure which can provide the key management service for the kernel

137

nameidata

struct nameidata

This field is a structure which facilitates the conversion of a pathname to real VFS based file object entity. Calls like stat(), open(), link() use this data structure

138

sysvsem

struct sysv_sem

CONFIG_SYSVIPC

This field stores all the semaphore information attached to the process or thread

139

sysvshm

struct sysv_shm

CONFIG_SYSVIPC

This field stores all the shared memory associated with this process or thread

140

last_switch_count

unsigned long

This field is used by the process hung detector which is used to track and identify the processes which have become unresponsive(blocked for a long time)

141

last_switch_time

unsigned long

142

fs

struct fs_struct

This field encapsulates the file system context of the process

143

files

struct files_struct

This field encapsulates the open files information of the process.

144

io_uring

struct io_uring_task

CONFIG_IO_URING

This field points to a pointer to io_uring which can help with submssion and retrieval of the I/ O operations for this process

145

nsproxy

struct nsproxy

This field is a pointer to various namespaces as implemented in Linux

146

signal

struct signal_struct

This field is a pointer to the signal_struct which handles the signals and process groups in the kernel

147

sighand

struct sighand_struct

This field acts as signal handler for the process. All the threads in the same process group share the same signal handler information

148

blocked

sigset_t

This field stores all the blocked signals by the process

149

real_blocked

sigset_t

This field is for real-time signals blocked by the process

150

saved_sigmask

sigset_t

This field stores the signal mask before a thread enters the critical section and restores it after coming out. This is part of the signal handling mechanism that the kernal performs.

151

pending

struct sigpending

This field holds all the signals which are waiting to be delivered to the thread or process

152

sas_ss_sp

unsigned long

SAS stands for Signal Alternate Stack, which is a feature where the user is allowed to use an alternative stack for handling the signals. By default, the process uses the user-space stack for handling the signals. sas_ss_sp is a pointer to the stack, sas_ss_size is the size of SAS stack and sas_ss_flags is the list of flags used to control the SAS stack

153

sas_ss_size

size_t

154

sas_ss_flags

unsigned int

155

task_works

struct callback_head

This field refers to the list of work items that are pending to be executed bythe process. Usually a callback mechanism is implemented for such queues.

156

audit_context

struct audit_context

CONFIG_AUDIT, CONFIG_AUDITSYSCALL

This structure is used by the Linux Audit Subsystem to collect and store information related to system calls and other auditable events by the process or thread

157

loginuid

kuid_t

CONFIG_AUDIT

This field represents the login user id of the user who initiated the session that spawned the current process

158

sessionid

unsigned int

CONFIG_AUDIT

This field identifies the session to which the process belongs to.

159

seccomp

struct seccomp

Secure Computing Mode(seccomp) is a fearure supported by kernel to filter the system calls made by the process,thereby enhancing the security by limiting the attack surface

160

syscall_dispatch

struct syscall_user_dispatch

The syscall user dispatch feature allows the userspace programs to register a handler that can incercept system calls before they are exeucted by the kernel. This helps in monitoring and analyzing system calls for debugging and performance analysis.

161

parent_exec_id

u64

This is counter which is available in each child process and its initial value is self_exec_id value from its parent.

162

self_exec_id

u64

A counter in the current process that is incremented each time the process successfully executes a new program using the execve() system call

163

alloc_lock

spinlock_t

Spinlocks are crucial for protecting shared data structures in the kernel from race conditins, specially in multi processor environments. alloc_lock is a spinlock which helps protect various critical fields in the proces or thread like 'fs', 'files', ''mm' etc

164

pi_lock

raw_spinlock_t

The 'raw' form of spinlock refers to the basic or low-level form of spinlock available in the kernel. These locks are designed for critical sections where interrupt handlers are already disabled or disabling is not required.

165

wake_q

struct wake_q_node

This is a pointer to a list of process or threads waiting to be woken up. Helps in cases where multiple processes are waiting to be woken up.

166

pi_waiters

struct rb_root_cached

CONFIG_RT_MUTEXES

This structure is used to manage and schedule the tasks virtual runtime as part of the CFS(Completely Fair Scheduler) scheduler mechanism

167

pi_top_task

struct task_struct

CONFIG_RT_MUTEXES

This field is a pointer used by the Linux's Real-Time(RT) mutex framework to handle the priority inversion, commonly seen in the kernel. This field points to the process with the highest priority waitign for the resources.

168

pi_blocked_on

struct rt_mutex_waiter

CONFIG_RT_MUTEXES

This field is a pointer to the RT mutex that this process is locked on.

169

blocked_on

struct mutex

This field points to the rt_mutex_waiter structure representing the process's wait on that specific mutex. Moslty a location holder of this process in the mutext list of waiters.

170

blocker

unsigned long

CONFIG_DETECT_HUNG_TASK_BLOCKER

Thsi fieldis used by the krnel to identiy what this process is waiting on or blocked by.

171

non_block_count

int

CONFIG_DEBUG_ATOMIC_SLEEP

This is a counter used by the kernel to detect potential deadlocks while the process is sleeping in the atomic sections. If the value is > 0, then a WARN_ON() warning is issued to the user-space process

172

irqtrace

struct irqtrace_events

CONFIG_TRACE_IRQFLAGS

This field is used to track the interrupt state of the process for the purpose of debugging and tracing

173

hardirq_threaded

unsigned_int

CONFIG_TRACE_IRQFLAGS

This field is used by the lock dependency validator(lockdep) to provide a finer grain control over the context of the interrupts.

174

hardirq_chain_key

u64

CONFIG_TRACE_IRQFLAGS

This field is a hash value of all the locks that are being held by the kernel to handle a hardware interrupt.

175

softirqs_enabled

int

CONFIG_TRACE_IRQFLAGS

These fields are related to the softirqs, a deferred interrupt handling mechanism which runs in the interrupt context and not process context

176

softirq_context

int

CONFIG_TRACE_IRQFLAGS

177

irq_config

int

CONFIG_TRACE_IRQFLAGS

178

softirq_disable_cnt

int

CONFIG_PREEMPT_RT

This field is used along with the per CPU counter to track if a specific task has disabled softirqs

179

curr_chain_key

u64

CONFIG_LOCKDEP

These fields are used by the kernel to implement the lock dependency validator feature to detect the deadlocks

180

lockdep_depth

int

CONFIG_LOCKDEP

181

lockdep_recursion

unsigned int

CONFIG_LOCKDEP

182

held_locks

struct held_lock

CONFIG_LOCKDEP

183

in_ubsan

unsigned int

CONFIG_UBSAN

This field is a counter used then UB scan reports are being generated. This field avoid infinite recursions in cases where a UB report generations calls itself.

184

journal_info

void

This field is to capture journalling related information related to a file system

185

bio_list

struct bio_list

This field is used as a queue for all the block I/O requests for the process

186

plug

struct blk_plug

This field is used to optimize the block I/O operations by plugging the I/O queue. This works by queueing all the I/O operations and submit them as a single request instead of multiple small requests.

187

reclaim_state

struct reclaim_state

This field is used to manage the memory reclaimation process for a process or thread when the system is under memory pressure

188

io_context

struct io_context

This field is responsible for managing the process's I/O scheduling and statistics, particulary in relation to block I/O

189

capture_control

struct capture_control

CONFIG_COMPACTION

This field helps with the memory compaction mechanism wherein when this process is captured, the associated memory pages are compacted to avoid page faults by this process.

190

ptrace_message

unsigned_long

This field is used to relay information to the traced process by the kernel.

191

last_siginfo

kernel_siginfo_t

This field is used to store the last received signal to the process

192

ioac

struct task_io_accounting

This field is used to store I/O accounting information for a process

193

psi_flags

unsigned int

CONFIG_PSI

This field is a bitmask used by the Pressure Stall Information(PSI) to track the process's resource-related stall events.

194

acct_rss_mem1

u64

CONFIG_TASK_XACCT

This field is used for memory accounting. RSS is the Resident Stack Size and holds the information related to the number of pages used by the process

195

acct_vm_mem1

u64

CONFIG_TASK_XACCT

This field stores the cumulative memory usage of the proces over its lifetime.

196

acct_timexpd

u64

CONFIG_TASK_XACCT

This field is used to store the CPU time for accounting purposes. It's value is updated by the kernel during the process's lifetime

197

mems_allowed

nodemask_t

CONFIG_CPUSETS

This field provides a mechanism to control and restrict the memory allocation to the NUMA nodes, primarily within the context of the cpusets feature, to improve performance and resource management in NUMA systems.

198

mems_allowed_seq

seqcount_spinlock_t

CONFIG_CPUSETS

This field is a counter to track the process memory policies, specially related to the NUMA nodes in use.

199

cpuset_mem_spread_rotor

int

CONFIG_CPUSETS

This field is used for controlling the memory placement in the cpuset's feature

200

cgroups

struct css_set

CONFIG_CGROUPS

This field is a pointer to a set of cgroup sub-system states for the process

201

cg_list

strcut list_head

CONFIG_CGROUPS

This field is used to link the process to the css_set list of processes

202

closid

u32

CONFIG_X86_CPU_RESCTRL

This field is a hardware level identifier used in Intel's Resource Director Technology(RDT). This is usually used to enable CPU resource control support.

203

rmid

u32

CONFIG_X86_CPU_RESCTRL

This field is used as a unique identifier for a process within the context of the hardware-assisted resource management and monitoring provided by the Intel's RDT technology.

204

robust_list

struct robust_list_head

CONFIG_FUTEX

When a process uses futexes for synchronization, it can register a list of futexes that it owns with the kernel. This field acts as a pointer to such a list.

205

compat_robust_list

strcut compat_robust_list_head

CONFIG_FUTEX, CONFIG_COMPAT

This field is an integral part of the robust futex mechanism that guarantees system stability and prevents deadlocks by correctly managing the state of the 32-bit application locks, even on 64-bit systems.

206

pi_state_list

struct list_head

CONFIG_FUTEX

These fields are used to manage process dependencies on the Priority-Inversion futexes. These make sure that high-priority processes are not blocked by low-priority processes indefinitely.

207

pi_state_cache

struct futex_pi_state

CONFIG_FUTEX

208

futex_exit_mutex

struct mutex

CONFIG_FUTEX

209

futex_state

unsigned int

CONFIG_FUTEX

210

perf_recursion

u8

CONFIG_PERF_EVENTS

These fields are used for enabling support for performance events provided by hardware and software.

211

perf_event_ctxp

struct perf_event_context

CONFIG_PERF_EVENTS

212

perf_event_mutex

struct mutex

CONFIG_PERF_EVENTS

213

perf_event_list

struct list_head

CONFIG_PERF_EVENTS

214

perf_ctx_data

struct perf_ctx_data

CONFIG_PERF_EVENTS

215

preempt_disable_ip

unsigned long

CONFIG_DEBUG_PREEMPT

This field holds the instruction pointer (IP) of the function that last disabled the preemption for this process.

216

mempolicy

struct mempolicy

CONFIG_NUMA

This field defines the memory allocation policy for a process or a specific region. It specifies how memory pages should be alocated, particularly from which NUMA nodes etc

217

il_prev

short

CONFIG_NUMA

This field identifiles the memory node allocated to the processes to implement the weighted memory interleaving allocation for the NUMA systems.

218

il_weight

u8

CONFIG_NUMA

This field allows the memory allocation policy to be weighted interleaving instead of the uniformed one for NUMA systems.

219

pref_node_fork

short

CONFIG_NUMA

This field stores the processes preferred NUMA node, when its created through fork() system call.

220

numa_scan_seq

int

CONFIG_NUMA_BALANCING

NUMA balancing feature helps to place the memory locations of the process in the NUMA node associated with the process. This feature scans the process memory pages in the other NUMA nodes to check if they can be migrated for better performance. This field 'numa_scan_seq' is a counter which helps with this feature. mostly used to avoid race conditions while performing the memory migrations.

221

numa_scan_period

unsigned int

CONFIG_NUMA_BALANCING

This field decides the period or duration of the memory scanning to identify for any possible memory migrations.

222

numa_scan_period_max

unsigned int

CONFIG_NUMA_BALANCING

This fileld sets the maximum scanning duration for the process. This upper bound is required to balance the performance that arises out of the NUMA enabled systems.

223

numa_preferred_nid

int

CONFIG_NUMA_BALANCING

This field indicates the preferred NUMA node for a process's memory allocation. Look's like a duplicate of pref_node_fork field.

224

numa_migrate_retry

unsigned long

CONFIG_NUMA_BALANCING

This field is a timestamp to prevent the kernel from frequently migrating the memory pages for a fast moving process.

225

node_stamp

u64

CONFIG_NUMA_BALANCING

This field is used to track the process's migration history in a NUMA enabled system.

226

last_task_numa_placement

u64

CONFIG_NUMA_BALANCING

This field is used by the scheduler to record the time of the process's last NUMA related memory placement decision.

227

last_sum_exec_runtime

u64

CONFIG_NUMA_BALANCING

This field is used to track the process's runtime for scheduling decisions, usually used by the CFS scheduler. Not sure how thi sis related to NUMA

228

numa_work

struct callback_head

CONFIG_NUMA_BALANCING

This field enables the automatic NUMA balancing by the kernel.

229

numa_group

struct numa_group

CONFIG_NUMA_BALANCING

This field is used to track NUMA related information for a process or a group of processes.

230

numa_faults

unsigned long

CONFIG_NUMA_BALANCING

This field stores the number of page faults that a process experiences on each NUMA node.

231

total_numa_faults

unsigned long

CONFIG_NUMA_BALANCING

This field is the cumulative number of page faults experienced by a process all through its lifetime.

232

numa_faults_locality

unsigned long

CONFIG_NUMA_BALANCING

This field is used to track the count of page faults in local and remote NUMA nodes.

233

numa_pages_migrated

unsigned long

CONFIG_NUMA_BALANCING

Thsi field keeps track of the number of memory pages migrated by the kernel on a NUMA system for this process.

234

rseq

struct rseq

CONFIG_RSEQ

These fields are used to implement the rseq() system call.

235

rseq_len

u32

CONFIG_RSEQ

236

rseq_sig

u32

CONFIG_RSEQ

237

rseq_event_mask

unsigned long

CONFIG_RSEQ

238

rseq_fields

char

CONFIG_RSEQ, CONFIG_DEBUG_RSEQ

239

mm_cid

int

CONFIG_SCHED_MM_CID

There is not much infomation available on whatthese fields and why they are used. They were introduced in 4.x in conjuction with the above RSEQ feature.

240

last_mm_cid

int

CONFIG_SCHED_MM_CID

241

migrate_from_cpu

int

CONFIG_SCHED_MM_CID

242

mm_cid_active

int

CONFIG_SCHED_MM_CID

243

cid_work

struct callback_head

CONFIG_SCHED_MM_CID

244

tlb_ubc

struct tlbflush_unmap_batch

This field is used to store the pages which are being unmapped from TLB. Instead of flusing them one at a time, they are done as a batch and they are stored here until the batch reaches a certain size.

245

splice_pipe

struct pipe_inode_info

This field is a process cached private pipe which is used in zero-copy transfers within splice() system call. This technique copies the data between two file descriptors without copying data to and from the user space.

246

task_frag

struct page_frag

This field is used for optmizing memory allocations, for networking subsystems.

247

delays

struct task_delay_info

CONFIG_TASK_DELAY_ACCT

This field is used to track the block I/O delays expereinced by the process.

248

make_it_fail

int

CONFIG_FAULT_INJECTION

These fields are related to the fault injection feature. WE use this feature for testing purposes.

249

fail_nth

unsigned int

CONFIG_FAULT_INJECTION

250

nr_dirtied

int

This field is used in the context of memory management. A memory page is considered dirty, when it is written over by the process but the changes have not been written to the persistent storage.nr_dirtied is a counter used to identify the number of dirty pages which are dirtied by this process.

251

nr_dirtied_pause

int

This field is used in the context when this process is aggreesively dirtying the pages and crossed over the per process threshold set by the kernel.

252

dirty_paused_when

unsigned long

This field holds the timestamp for the beginning of the write-and-pause period of the process's pages.

253

latency_record_count

int

CONFIG_LATENCY_TOP

This field is used in the context of latency calculations by the kernel. This feature allows the kernel to keep a track of the longest delays caused by various operations. latncy_record_count field is used to store the scheduling latency events caused by this process.

254

latency_record

struct latency_record

CONFIG_LATENCY_TOP

This field stores the latency event caused or expereinced by this process. This is an array

255

timer_slack_ns

u64

These fields are used to round-up the poll() and select() timer values(these are in nanoseconds)

256

default_timer_slack_ns

u64

257

kasan_depth

unsigned int

CONFIG_KASAN_GENERIC or CONFIG_KASAN_SW_TAGS

Kernel Address Sanitizer(KASAN) is a dynamic memory error detector. kasan_depth field is a counter used to track the resursion depth during memory allocation and deallocation.

258

kcsan_ctx

struct kcsan_ctx

CONFIG_KCSAN

This field stores the information related to the Kernel Concurrency Sanitizer (KCSAN). KCSAN is used to track the concurrency bugs in the kernel.

259

kcsan_save_irqtrace

struct irqtrace_events

CONFIG_KCSAN, CONFIG_TRACE_IRQFLAGS

This field stores the IRQ trace state when the KCSAN is active

260

kcsan_stack_depth

int

CONFIG_KCSAN, CONFIG_KCSAN_WEAK_MEMORY

This field stores the stack depth of the kernel for this process. Used in conjuction with KCSAN feature.

261

kmsan_ctx

struct kmsan_ctx

CONFIG_KMSAN

KMSAN is Kernel Memory Sanitizer, used for tracking the uninitialized memory in the kernel. kmsan_ctx field stores the per process state of the KMSAN detector.

262

kunit_test

struct kunit

CONFIG_KUNIT

This field is a pointer used by the kUnit test frameworkto associate a running kernel thread/ process with the test context that spawned it.

263

curr_ret_stack

int

CONFIG_FUNCTION_GRAPH_TRACER

The tracer is a debugging and profiling tool in the kernel that records the entry and exit of the functions. This field is a pointer to a process specific 'shadow stack' that holds the return addresses of the instrumented function calls.

264

curr_ret_depth

int

CONFIG_FUNCTION_GRAPH_TRACER

These fields are used to track the call stack of the kernel functions

265

ret_stack

unsigned long

CONFIG_FUNCTION_GRAPH_TRACER

266

ftrace_timestamp

unsigned long long

CONFIG_FUNCTION_GRAPH_TRACER

There is not much information available for these fields, but they are used in the ftracer debugging tool.

267

ftrace_sleeptime

unsigned long long

CONFIG_FUNCTION_GRAPH_TRACER

268

trace_overrun

atomic_t

CONFIG_FUNCTION_GRAPH_TRACER

269

tracing_graph_pause

atomic_t

CONFIG_FUNCTION_GRAPH_TRACER

270

trace_recursion

unsigned long

CONFIG_TRACING

Not much information is available about this field.

271

kcov_mode

unsigned int

CONFIG_KCOV

These fields help with getting the kernel code coverage for fizzing purposes.

272

kcov_size

unsigned int

CONFIG_KCOV

273

kcov_area

void

CONFIG_KCOV

274

kcov

struct kcov

CONFIG_KCOV

275

kcov_handle

u64

CONFIG_KCOV

276

kcov_sequence

int

CONFIG_KCOV

277

kcov_softirq

unsigned int

CONFIG_KCOV

278

memcg_in_oom

struct mem_cgroup

CONFIG_MEMCG_V1

This field is used to indicate if the process is involved in a memory cgroup out-of-memory event.

279

memcg_nr_pages_over_high

unsigned int

CONFIG_MEMCG

This field is used to track the number of memory pages this process has allocated that exceeds the its memory cgroup's 'high' limit.

280

active_memcg

struct mem_cgroup

CONFIG_MEMCG

CONFIG_MEMCG acts as a memory controller for the cgroups. mem_cgroup is a structure for the memory controller for each cgroup. active_memcg is a fpointer to the memory control group that is active for this process. It is primarily used to track and enforce memory usage limits imposed by the cgroup memory controller.

281

objcg

struct obj_cgroup

CONFIG_MEMCG

This field represents a list of memory objects associated with the memory cgoup

282

throttle_disk

struct gendisk

CONFIG_BLK_CGROUP

This field is used to disk I/O throttling purposes where disk bandwidth and operations per second are limited for a specific process of group of processes.

283

utask

struct uprobe_task

CONFIG_UPROBES

Uprobes are the user space probes which are used for probing the applications. Its the counter part to kernels Kprobes. utask is a variable which holds the metadata for a specific process when it is being instrumented by a user level probe.

284

sequential_io

unsigned int

CONFIG_BCACHE or CONFIG_BCACHE_MODULE

CONFIG_BCACHE allows a block device to be used as a cache for other devices. sequential_io is a field used by the kernel to track and average the process's sequential I/O patterns.

285

sequencial_io_avg

unsigned int

CONFIG_BCACHE or CONFIG_BCACHE_MODULE

286

kmap_ctrl

struct kmap_ctrl

This field is used to manage the mapping of the high memory pages within a single process.

287

task_state_change

unsigned long

CONFIG_DEBUG_ATOMIC_SLEEP

These fields are used to change the state of the process.

288

saved_state_change

unsigned long

CONFIG_DEBUG_ATOMIC_SLEEP, CONFIG_PREEMPT_RT

289

rcu

struct rcu_head

This field is used by RCU for syncronization.

290

rcu_users

refcount_t

This field is used to manage the RCU based references.

291

pagefault_disabled

int

This field is used to check if the page faults have been disabled for this process.

292

oom_reaper_list

struct task_struct

CONFIG_MMU

This field adds the process to the oom_reaper kernel thread for cleanup of its memory managmenet structures

293

oom_reaper_timer

struct timer_list

CONFIG_MMU

This field is used to schedule the OOM reaper scheduler.

294

stack_vm_area

struct vm_struct

CONFIG_VMAP_STACK

This field is used when configuring virtual ly enabled kernel stacks. This mechanism allows the kernel stack buffer overflows to be caught without causing data corruptions.

295

stack_refcount

refcount_t

CONFIG_THREAD_INFO_IN_TASK

This field holds the number of references to the process kernel stack.

296

patch_state

int

CONFIG_LIVEPATCH

This field is used for live patching the kernel to track the security vulnerabilities.

297

security

void

CONFIG_SECURITY

This field allows to chose a security model for the kernel.

298

bpf_storage

strcu bpf_local_storage

CONFIG_BPF_SYSCALL

This field alllows to attach BPF defined storage to this process. This mechanism allows BPF to store and access the private data of the process context.

299

bpf_ctx

struct bpf_run_ctx

CONFIG_BPF_SYSCALL

This field supports the adavanced eBPF features.It allows the BPF programs to associate with the runtime context of the process.

300

bpf_net_context

struct bpf_net_context

This field stores the network based context for BPF programs for this process.

301

lowest_stack

unsigned long

CONFIG_KSTACK_ERASE

This field is used to detect the kernel stack buffer overflow in old kernel versions.

302

prev_lowest_stack

unsigned long

CONFIG_KSTACK_ERASE_METRICS

This field is used to track the kernel stack usage.

303

mce_vaddr

void

CONFIG_X86_MCE

These fields are used for configuring the machine checks. This setting allows the processes to notify the kernel if it detects any issues related to heating, data corruption etc.

304

mce_kflags

u64

CONFIG_X86_MCE

305

mce_addr

u64

CONFIG_X86_MCE

306

mce_ripv

u64

CONFIG_X86_MCE

307

mce_kill_me

struct callback_head

CONFIG_X86_MCE

308

mce_count

int

CONFIG_X86_MCE

309

kretprobe_instances

struct llist_head

CONFIG_KRETPROBES

This field is used when kernel tracing is enabled. With Kernel tracing, we can dynamically break into any kernel routine for debugging and performace related information.

310

rethooks

struct llist_head

CONFIG_RETHOOK

This field enables return hook feature, usually used by other hooking featues like fprobe and kprobes

311

l1d_flush_kill

struct callback_head

CONFIG_ARCH_HAS_PARANOID_L1D_FLUSH

This field is used as a kill swITch for processes which are not running on SMT disabled cores.

312

rv

union rv_task_monitor

CONFIG_RV

This field is used to enable and monitor the kernels runtime verification substem

313

user_event_mm

struct user_event_mm *

CONFIG_USER_EVENTS

This field associates this process with the Linux Kernels User Event tracing subsystem

314

unwind_info

struct unwind_task_info

CONFIG_UNWIND_USER

Thie field refers to the call stack unwinding feature for the user space programs, meant to examine the call stack in the running state.

315

thread

struct task_struct

This field stores the CPU specific state of this process.

struct vm_area_struct

virtual memory areas(VMAs) are defined by a data structure ‘struct vm_area_struct’ defined in ./linux/mm_types.h.

VMAs are used to define the memory areas associated with a process. Read more about it in the ‘Process Management’ blog

sl no

Attribute name

Attribute type

Attribute Usage

1

vm_start

unsigned long

Beginning of a virtual memory area

2

vm_end

unsigned long

End of a virtual memory area

3

vm_mm

struct mm_struct

This pointer points back to the process address space, this VMA belongs to

4

vm_page_prot

pgprot_t

Permissions associated with the memory area(READ, WRITE, EXECUTE)

5

vm_flags

vm_flags_t

flags used to manipulate the memory areas(like permissions, sharing etc)

6

vm_lock_seq

unsigned int

lock for this memory area

7

anon_vma_chain

struct list_head

Used by anonymous memory areas usually created by calls to malloc() ( referred to as heap region too)

8

anon_vma

struct anon_vma

9

vm_ops

struct vm_operations_struct

refers to the operations that can be executed on the vmas(like open, remove, access etc).

10

vm_pgoff

unsigned long

Refers to the page offset, usally associated with the vm_file information below.

11

vm_file

struct file

When vma is associated with a file, this pointer points to that file, otherwise NULL. Say, the process open a file, that file content is stored in some memory and that memory is referred by this vma

12

vm_private_data

void

Used when shared memory is involved between processes

13

swap_readahead_info

atomic_long_t

used when SWAP is enabled

14

vm_region

struct vm_region

Used when MMU is enabled by the kernel

15

vm_policy

struct mempolicy

Defines the NUMA policy for the VMA

16

numab_state

struct vma_numab_state

Relates to NUMA related policy

17

vmlock_dep_map

struct lockdep_map

enabled when CONFIG_DEBUG_LOCK_ALLOC is used

18

anon_name

struct anon_vma_name

Name associated with the VMA or a NULL

19

vm_userfaultfd_ctx

struct vm_userfaultfd_ctx

Related to the system call userfaultfd(), used when tracking the user faults associated with this VMA

20

pfnmap_track_ctx

struct pfnmap_track_ctx *

Used when Physical Frame Tracking (PFN) is enabled

]]><![CDATA[Linux Kernel Initialization]]>https://linux-kernel.hashnode.dev/core-kernel-initializationhttps://linux-kernel.hashnode.dev/core-kernel-initializationThu, 16 Oct 2025 02:02:27 GMTThis blog is to understand how the Linux kernel is installed and initialized in the physical memory.

Linux Boot Process:

  • When we start the system, initial control goes to the BIOS firmware, sitting on a chip on the motherboard.

  • This software starts with checking if the hardware is working fine. This process is called Power-On-Self-Test(POST).

  • Once POST completes, BIOS checks the boot order. BIOS tries to boot from the first available boot disk(USB, hard drive etc).

  • Lets say, the system is trying to boot from a hard drive.

  • BIOS tries to locate the Master Boot Record(MBR) from the hard drive. MBR is a 512 bytes(always) present in the Disk 0, Sector 1 and Head 0 location. This location is hard coded.

  • BIOS moves MBR to the physical memory. MBR has the location of the boot loader. For example, GRUB, LILO etc. Let’s say we are using GRUB.

  • MBR loads the GRUB files into the physical memory. This is when we see the menu options with all the available operating systems and versions. Users are expected to choose one in this list.

    We can access the GRUB files at ‘/boot/grub/grub.cfg’ location. We can modify the contents by changing the file ‘/etc/default/grub’.

  • Boot loader has access to two files:

    1. first is the linux kernel executable, which is usually named, vmlinuz-*. This is the file which controls the entire system and hardware once loaded and initialized later.

    2. Second is a file called initial RAM disk, usually named ‘initrd-*’. The purpose of this file will be explained further.

  • Boot loader loads the linux kernel executable file first into the physical memory. But where does it load it?

    • This depends on the kernel configurations, like CONFIG_PHYSICAL_START, CONFIG_PHYSICAL_ALIGN, CONFIG_RANDOMIZE_BASE.

      On Linux Kernel-6.11, these values are as below:

    • These values show that the kernel is installed on the physical memory at 0x1000000 location( 100 MB) from the beginning of the physical memory. Since a static location is not safe, the latest implementations randomize this location. This is done by configuring CONFIG_RANDOM_BASE to ‘y’ during building the kernel.

      Also, the size of the memory allocation for Kernel depends on the build configurations used, but is usually 1 GB as shown below.

      More about this will be discussed in another blog.

  • Initially the kernel is in compressed format to ease the time to load to the memory. Once it's loaded, it de-compresses itself. Then the first activity it does is to mount the ‘initrd’ files on a file system called ‘initramfs’. This is an intermediary step before the kernel mounts the actual root file system.

  • From the ‘initramfs’ file system, kernel executes some assembly code, which is usually present in location ./arch/x86/kernel/head_{32 | 64}.S (depending on 32 vs 64 bit systems).

  • This assembly code is architecture dependent. The goal of running this assembly code is to execute a C type method called ‘start_kernel’.

  • Start_kernel completes the initialization of the kernel to its fullest form, upon which it mounts the root file system, starts the ‘init’ process and provides the user a login prompt.

Kernel Memory Sections

We noted earlier that the kernel occupies around 1 GB of memory in the physical memory during the above boot process.

This allocation consists of multiple sections as shown below:

  • 22528K kernel code: This is the executable machine code of the kernel itself, stored in the .text segment. This section is typically read-only.

  • 4524K rwdata: Short for read-write data, this memory contains global and static variables that have been initialized with a non-zero value. It is stored in the .data segment and can be modified at runtime.

  • 15008K rodata: Short for read-only data, this memory holds constant data that should not change during execution, such as string literals. It is stored in the .rodata segment.

  • 4884K init: This is temporary kernel initialization memory. After the system is booted, this memory is released back to the general memory pool to be reused.

  • 4736K bss: Short for Block Started by Symbol, this section contains uninitialized global and static variables. The kernel initializes this memory to zero at boot.

  • 995728K reserved: This is a large block of memory reserved by the firmware for hardware functions that the kernel does not manage. It is typically not available for general-purpose use.

  • 0K cma-reserved: This field refers to "Contiguous Memory Allocator" reserved memory, which is used for device drivers that require large, physically contiguous memory blocks. In this case, none is reserved.

These values are typical for a RAM of size 16 G. We can get these values for a system from ‘dmesg’ logs, as below(last line):

The rest of the blog is to understand what happens in ‘start_kernel’ code.

Core Kernel Initialization

  • [set_task_stack_end_magic()] creates a kernel stack and adds a canary value 0x57AC6E9D at the end of the stack to check for buffer overflows, As shown in the below picture.

  • The size of this stack is architecture dependent. This stack is created in the kernel memory section ‘bss’ in the physical memory(RAM). The size is usually PAGE_SIZE or 2 * PAGE_SIZE. A page size is usually 4096 or 8192 bytes.

    • How do you get this value on your system?

      To get the page size, you can use the command, ‘getconf PAGESIZE’ on the terminal, as below:

To get the kernel stack size, you can use the command ‘ulimit -s’ as below:

  • Whether the kernel stack grows upwards or downwards is based on the setting ‘CONFIG_STACK_GROWSUP’ and is platform dependent. For example, for x86 or ARM or PPC, this is not set and the stack grows downwards.

  • [smp_setup_processor_id()] Creates a CPU logical map for fetching logical processor id for a given physical CPU Id. This is required to manage and identify CPUs consistently across the system. For systems with multi-processor systems, where CONFIG_SMP is set, the values range from 1…n

  • [local_irq_disable()] Disable hardware interrupts on the CPU where the init process is running. These interrupts will be inactive until the init process is completed.

  • [boot_cpu_init()] Decide which CPU Id to boot kernel from. In single CPU system, this would be 0.

  • [page_address_init()] Create a 128 sized array of type ‘struct page_address_slot’ which is used to get the virtual address for a page in the highmem region. More about this will be discussed in a future blog.

  • 💡
    All the memory allocations from the below step are fulfilled through ‘memblock’. This is a boot time memory management system where memory is allocated in ‘regions’ directly in the physical memory. No virtual addressing happens here.

  • [setup_arch()] All the architecture specific setup here:

    • Load the kernel PGD (Page Global Descriptor) table to CPU’s CR3 register( only for 32 bit system)

    • Flush the TLB cache to remove any garbage entries(32 bit).

    • Set the MAX_PHYSMEM_BITS value which is used for addressing the virtual address space.

    • Reserve memblock region for the .text region of the kernel. Kernel memory sections have been described earlier.

    • Reserve memblock region for the initrd image.

    • Reserve memblock region for data part of the kernel.

    • Reserve memblock region for the init process. This memory is claimed back once the init process is started and moved to the user space.

    • Randomize the kernel base memory if CONFIG_RANDOMIZE_BASE is enabled.

    • Initialize the Interrupt Descriptor Table(IDT) which maps the interrupt or exception number to a memory address that handles it. This allows the CPU to avoid any unexpected events before the system is fully configured.

  • [setup_nr_cpu_ids()] Calculate the number of CPUs in the system and assign this value to the variable ‘nr_cpu_ids’. This value is used in all cases where CPU operations are involved.

  • [setup_per_cpu_areas()] Initialize memory for ‘per-CPU’ variables. This feature allows a copy of a variable to be made available(usually in L3 cache) for each CPU and thereby allow the CPUs to read the local copy instead of using locks to fetch its value from the physical memory.

  • [setup_log_buf()] Setup a log buffer of size 128 KB. All the messages that ‘printk’ logs, are stored in this buffer. These messages can be accessed using the ‘dmesg’ shell command .

  • [sort_main_extable()] Sort the kernel exception handlers table. This list is required to handle any exceptions seen by the kernel and make sure the system doesn’t crash.

  • [sched_init()] Initialize the scheduler, for task scheduling ahead. All the scheduler algorithms (like DL, RR, FAIR etc) are initialized here.

  • [trace_init()] Initialize tracing infrastructure, part of the ‘ftrace’ framework. Trace events are generated after this step.

  • [kfence_init()] Initialize Kernel Electric Fence(KFence) memory error detector. This tool is designed to detect common heap memory errors like out-of-bounds access, use-after-free and invalid-free errors.

  • [lockdep_init()] Initialize the lock dependency validator, which is a tool to detect the potential deadlocks and incorrect locking patterns within the kernel.

  • [anon_vma_init()] Create slab cache called ‘anon_vma’ for kernel objects of type ‘struct anon_vma’, which is used to manage the anonymous virtual memory. This memory refers to the virtual memory which is not backed by a file or disk, like a process’s stack or heap.

  • [thread_stack_cache_init()] Create slab cache named ‘thread_stack’ for kernel threads.

  • [fork_init()] Allocate slab cache named ‘task_struct’ for kernel objects of type ‘struct task_struct’. This structure holds the information about a single process.

  • [proc_caches_init()] Create slab caches for the below kernel objects:

    • slab cache named ‘sighand_cache’ for kernel objects ‘struct sighand_struct’.

    • slab cache named ‘signal_cache’ for kernel objects ‘struct signal_struct’.

    • slab cache named ‘files_cache’ for kernel objects ‘struct files_struct’

    • slab cache named ‘fs_cache’ for kernel objects ‘struct fs_struct’.

    • slab cache named ‘vm_area_struct’ for kernel objects ‘struct vm_area_struct’.

  • [security_init()] Initialize the Linux Security Module (LSM) framework by loading all the LSM modules which were enabled in the boot config.

  • [net_ns_init()] Create slab cache called ‘net_namespace’ for kernel objects of type ‘struct net’ . Network namespaces allow for network isolation and each namespace can have its own network stack(ip addresses, firewalls, routing etc). This allows for launching multiple applications and services (isolated from each other) on a single Linux system. This is similar to container and virtual machine technologies which we use today.

  • [vfs_caches_init()] Initialize Virtual File System(VFS) by creating slab caches for kernel objects like directory entries, inodes, file objects, mount points, buffers for storing and accessing the files.

  • [pagecache_init()] Initialize page cache mechanism. As part of this setup, an array of size 256 is created to hold the information of the processes or threads which are waiting for a particular page to be made available. These are called wait queues. That means each page in the page cache, gets a wait queue of this size to hold information of the processes or threads waiting to access this page. This step also creates kernel threads and other data structures used to handle the ‘dirty’ pages, these are pages which have been modified by the process or thread, but not written back to the secondary storage.

  • [signals_init()] Create slab cache for kernel objects of type ‘struct sigqueue’.

  • [seq_file_init()] Initialize seq_file which is used to create virtual files later in the other file systems like ‘proc’. Virtual files are dynamically created when requested for. All the content in the /proc folder is created by this seq_file mechanism.

  • [proc_root_init()] Mount ‘proc’ file system. Mount ‘sys’, ‘fs’, ‘driver’, ‘’tty’, ‘sys’ file systems under ‘proc’ file system.

  • [nsfs_init()] Initialize and mount ‘nsfs’ file system. This file system helps with Linux namespaces, which are used to isolate the processes for optimizing the system resources. This file system cannot be mounted and usually is available through the proc file system. This file system helps to find which namespace is being used for a particular process.

  • [pidfs_init()] Initialize the ‘pidfs’ pseudo file system by creating the required data structures and mounting it. This file system is usually used within the kernel to manage the process Ids and related information.

  • [cpuset_init()] Initialize cpusets as part of the cgroup controllers. This step allows group of processes to limit access to cpusets.

  • [mem_cgroup_init()] Create a slab cache called ‘mem_cgroup’ to create kernel objects of type ‘struct mem_cgroup’.

  • [cgroup_init()] Initialize control groups (cgroup). Mount the file system ‘/sys/fs’ as ‘cgroup’ and create cgroup files like ‘cgroup.procs’ etc, as shown below:

  • [taskstats_init_early()] Assign slab cache memory for the structure ‘taskstats’ which would be used for delay accounting subsystem.

  • [delayacct_init()] Initializes delay accounting subsystem, which tracks the and reports delays experienced by the tasks(processes and threads) waiting for kernel resources. This information is made available to user-space through the taskstats interface. This step involves assigning cache memory to store this information and then initiate this accounting for the initial ‘init’ process.

  • [acpi_subsystem_init()] Initialize ACPI system. ACPI stands for Advanced Configuration and Power Interface which is an in-built power management mechanism which shuts down parts of the system which are not in use to save power. Usually helpful for laptops.

  • [kcsan_init()] Initializes KCSAN tool which can detect data races within the kernel code. We can enable this tool by using the setting CONFIG_KCSAN=y and then compile the kernel. Initialization happens by adding a random value to per_cpu_data called ‘kcsan_rand_state’ variable.

  • [rest_init()] As a last step, spawns ‘init’ process as a user space process and assigns PID of 1 and spawns kernel thread ‘kthreadd’ and assigns it a PID of 2. A new ‘idle’ process is created (also called swapper process) with PID 0. This swapper process is scheduled by the scheduler when no other process is available to be scheduled on the CPU.

    • How do you identify kernel threads ? These are process which are reported in [] brackets when you run ‘ps’ command, as shown below:

  • As you can see here, PID 1 is assigned to init process, PID 2 is assigned to first kernel thread ‘kthreadd’ and all the kernel threads are created by this thread and have a parent PID of 2 and are displayed in square brackets ([]).
]]>