Linux process address space, core stack, user stack, kernel thread

Linux process address space, core stack, user stack, kernel thread

Address space:

On a 32-bit Linux system, the process's address space is 4G, including the 1G kernel address space, and the 3G user address space.

Kernel Stacks:

2 page size information is saved in the Process Control block task_struct .

Why is each process using its own kernel stack?

Reference (http://hi.baidu.com/iruler/blog/item/0c3363f377ccc5c90a46e023.html) "

Suppose a process runs through a system call in the kernel state (using this global kernel stack), if it is preempted, a switchover occurs, another process starts running, and if the current process is stuck in the kernel through a system call, the process will also use the global kernel stack. In this case, the kernel space stack of the previous process is destroyed. And if the process uses a separate kernel stack, it avoids the situation

Kernel Threads:

A dispatch unit with its own independent kernel stack that can participate in scheduling and execution in kernel space.

user stack:

Each thread has a user stack, which is pointed to by SS and esp.

===================================================

Process 1 Process 2

Kernel code Area kcode (0xc0001000) Kcode (0xc0001000)

Kernel stack area kstack (0xc000f000) kstack (0xc001F)

Kernel stack area kstack (0xc000d000) kstack (0xc001D000)

...

Kernel data area kdata (0xc0003000) kdata (0xc0003000)

---------------------------------------------------------------------------------------------

User code Area Ucode (0x70001000) ucode (0x70001000)

User Stack area ustack (0x7000f000) ustack (0x7000f000)

User Stack area ustack (0x7000d000) ustack (0x7000d000)

...

User Data area udata (0x70003000) udata (0x70003000)

===================================================

A reasonable explanation:

The Map page table for the kernel 1G space (256 entries*4m) has only one copy, n processes shared (both copies a copy of the entries of the entries+768 user space in their Process page table, 256 cores, 1024 entries, assuming 4M pages , and are all allocated at the outset).

These entries are different for each process user space, for example, the same 0x70001000 virtual address, process 1 points to physical memory 0x2000, and process 2 points to 0x1000.

The virtual address of the kernel stack corresponding to each thread does not overlap.

Thread1 ' s kernel stack = 0f000,

Thread2 ' s kernel stack = 0d000,

Thread3 ' s kernel stack = 1f000,

Thread4 ' s kernel stack = 1d000

...

Think 1:

If the kernel stack is not pre-allocated (meaning "a piece of non-overlapping space in the kernel space as a stack for each thread", e.g. Kmalloc call), then step into the kernel state, press the stack, a page fault occurs, you must be on the core stack occupied by page to be changed, And the call of the process of paging will inevitably involve the stack of parameters, and this time the kernel stack is not ready, exception occurred nested, system error!

Think 2:

Inside the kernel to do kmalloc is OK, add a entries, associated with a piece of physical memory, okay can be used.

Think 3:

If you want the process to share data from a virtual memory address 0x80001000, add 1 entries (0x80001000->0x3000) to the page table P1,P2 the process that needs to be shared.

In addition, the kernel is a natural shared object, so only one copy of the Kernel Space page table is set in each process .

If a guy is a maverick, creating n a page table about kernel space, pointing to n blocks of physical memory, then he needs to "lay" a copy of n-kernel code and data in these n physical memory (really asking for trouble).

Think 4:

The kernel stack is really not suitable for sharing (a special area of memory). What to do? Pinned to a virtual address like a user-space stack, the entries points to different physical memory? Obviously not! There is only one way to allocate n non-overlapping spaces within the kernel space.

Think 5:

When the kernel comes in, the original "kernel stack" is not the real kernel stack, the stack is global, and each CPU is a transition to the real kernel stack. (http://bbs.pediy.com/archive/index.php?t-87518.html)

Think 6:

Stand-alone kernel stack scenarios, at first let's analyze what happens if you share a kernel stack. , assuming there is a, B three processes, a call system call Read (1,...) Read the button, right now there is no button,
So a is blocked in the kernel, when the kernel dispatch b executes, at this point B also calls a system call is blocked, and when the key event arrives, process A is awakened, a continues to execute. Let's think about B entering the kernel
< Span style= "Font-family:song,verdana; font-size:18px; line-height:28px; " > has destroyed a kernel stack that goes into the kernel, does a return normally? So from the above analysis A, B must have their own core stack. This kernel stack appears to be the
Altogether 3 pages were allocated, except for the task_struct-occupied memory, The rest is the kernel stack. On the x86, the stack and other pointers are stored in the SS0 and Esp0 of the TSS break. (http://bbs.chinaunix.net/thread-1930753-1-1.html)

Resources:

1, Kernel stack usage (http://tech.ddvip.com/2008-09/122095404362368.html)

Linux process address space, core stack, user stack, kernel thread