First Question:
Does the kernel mode stack of each process need to be always present in the physical memory (i.e. they can't be swapped out)?
------------------------------------------------------------------------------------------------------------------------------------------------------------
Another question is about how Linux (2.6+) orgainises the memory mapping for kernel mode stacks:
For example, when a new process, say A , is created, the kernel must allocate a certain amount of memory in its address space for the kernel mode stack plus thread_info struct.
and the linear address of this memory must be mapped into a region of physical memory by paging mechanism. Let's say this linear address is 0x015FA000 and it is mapped to the physical memory
0x04502000.
Now is my second question:
If B and C are processes that have existed even before process A was created, will B and C's page tables include the entry ( 0x015FA000,0x04502000) into their page tables also?
If this is the case, does that mean every time a new process is created, this mapping must be included in the page table of every process?
Last Question:
is the linear address for a kernel mode stack in the last Gigabyte of the process address space (0xC0000000) or they could reside any where below ( with the U/S bits in the corresponding page entries set) ?
Kernel Mode Stack
Re: Kernel Mode Stack
I do not know specifics about Linux, or much about higher-half kernels.
1. No. The current process can be interrupted at any time. And the three times when you need a kernelmode stack are: when the scheduler swaps the process "in", on an interrupt, and when the scheduler swaps the process "out". So the kernelmode stack for a thread must be loaded constantly while each thread is running. During the time when a thread is swapped out, its kernelmode stack is unused.
2. No process A needs to know anything about the memory of process B, unless they share memory. Ever. Your virtual memory manager handles that.
3. Higher-half kernels are generally built that way so that the kernel is accessible without ever having to change the page tables for that upper memory. So, I would think you would want to have the kernelmode stack in the other half.
1. No. The current process can be interrupted at any time. And the three times when you need a kernelmode stack are: when the scheduler swaps the process "in", on an interrupt, and when the scheduler swaps the process "out". So the kernelmode stack for a thread must be loaded constantly while each thread is running. During the time when a thread is swapped out, its kernelmode stack is unused.
2. No process A needs to know anything about the memory of process B, unless they share memory. Ever. Your virtual memory manager handles that.
3. Higher-half kernels are generally built that way so that the kernel is accessible without ever having to change the page tables for that upper memory. So, I would think you would want to have the kernelmode stack in the other half.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: Kernel Mode Stack
long answer: (bewing beat me to the short version)
I remember someone having the signature
"Things not to do in an OS #1: Swapping out page swapping code - triple fault here we come"
- you have all kernel stacks and task structs mapped in kernel space. That means that when you add one, it immediately becomes visible for all address spaces since they are sharing page directories. This is the straightforward approach, and most likely the one Linux uses. Knowing what each task is doing can help the kernel when it switches threads.
And unlike bewing is suggesting, it is the kernel that needs to know about everything - whatever is in kernel land is accessible to the kernel alone so each task will end up not knowing about other tasks unless they ask the kernel.
- You only map the structures needed for that address space. This means you are not limited to the kernel range to map tasks. It does pose a problem when you want to access other process' information, but with some clever tactics, you can get around that. My OS works this way, and the disadvantage is turned over as a mapped task structure means ownership over that task. (and if not's mapped, you can't see it).
Identity paging (or no paging) has some advantages of its own and is therefore the common second choice. That means the kernel is mapped at 1M and simply turning off paging usually keeps it in working condition (other design conditions permitting).
When you enter kernel land, you are automatically using the kernel stack. If its not in memory, that it will crash the moment kernel mode is entered (which you probably need to do to map the page)miyano2005 wrote:Does the kernel mode stack of each process need to be always present in the physical memory (i.e. they can't be swapped out)?
I remember someone having the signature
"Things not to do in an OS #1: Swapping out page swapping code - triple fault here we come"
I don't know how Linux works exactly here, but there are generally two methods:Another question is about how Linux (2.6+) orgainises the memory mapping for kernel mode stacks
- you have all kernel stacks and task structs mapped in kernel space. That means that when you add one, it immediately becomes visible for all address spaces since they are sharing page directories. This is the straightforward approach, and most likely the one Linux uses. Knowing what each task is doing can help the kernel when it switches threads.
And unlike bewing is suggesting, it is the kernel that needs to know about everything - whatever is in kernel land is accessible to the kernel alone so each task will end up not knowing about other tasks unless they ask the kernel.
- You only map the structures needed for that address space. This means you are not limited to the kernel range to map tasks. It does pose a problem when you want to access other process' information, but with some clever tactics, you can get around that. My OS works this way, and the disadvantage is turned over as a mapped task structure means ownership over that task. (and if not's mapped, you can't see it).
HigherHalf is one of two common norms. Practically, you can map your kernel whereever you want it to be, but not splitting memory in two is usually considered an advantage (and hence, kernel ranges from C0000000-FFFFFFFF or sometimes 80000000-FFFFFFFF). For linux, there's a configuration option to set this.is the linear address for a kernel mode stack in the last Gigabyte of the process address space (0xC0000000) or they could reside any where below ( with the U/S bits in the corresponding page entries set) ?
Identity paging (or no paging) has some advantages of its own and is therefore the common second choice. That means the kernel is mapped at 1M and simply turning off paging usually keeps it in working condition (other design conditions permitting).
- xenos
- Member
- Posts: 1118
- Joined: Thu Aug 11, 2005 11:00 pm
- Libera.chat IRC: xenos1984
- Location: Tartu, Estonia
- Contact:
Re: Kernel Mode Stack
I think there is a way to swap out kernel stacks, but I would certainly not recommend it: If an exception occurs and the kernel stack is not present, that leads to a double fault. To handle this properly, you need to call the double fault handler through a task gate, which provides a new page directory and a kernel stack. That's a very dirty solution and I don't know if it works at all... Just don't do it.
Re: Kernel Mode Stack
Hi,
I agree that it's not a good idea, but as an addition to the above, if you are in 64 bit mode you always have the IST fields that you can use in order to provide a clean stack for exception / interrupt handling.
Cheers,
Adam
I agree that it's not a good idea, but as an addition to the above, if you are in 64 bit mode you always have the IST fields that you can use in order to provide a clean stack for exception / interrupt handling.
Cheers,
Adam
-
- Posts: 6
- Joined: Thu Sep 06, 2007 8:44 am
Re: Kernel Mode Stack
Thanks a lot for the answers and the discussions.