When is the page table of a process loaded in memory?
I'd like to know when is the page table of a particular process loaded in main memory by the OS? Is it when the process gets scheduled? Is the OS capable of directly loading the process page table into main memory?
I had a notion that nothing gets into main memory unless a page fault corresponding to a page is generated by the processor. Does the same apply for page tables too? Or is my notion incorrect.
PS: If the answer could be specific to Linux based systems, it'd be highly appreciated.
linux cpu virtual-memory
bumped to the homepage by Community♦ 4 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
I'd like to know when is the page table of a particular process loaded in main memory by the OS? Is it when the process gets scheduled? Is the OS capable of directly loading the process page table into main memory?
I had a notion that nothing gets into main memory unless a page fault corresponding to a page is generated by the processor. Does the same apply for page tables too? Or is my notion incorrect.
PS: If the answer could be specific to Linux based systems, it'd be highly appreciated.
linux cpu virtual-memory
bumped to the homepage by Community♦ 4 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
I'd like to know when is the page table of a particular process loaded in main memory by the OS? Is it when the process gets scheduled? Is the OS capable of directly loading the process page table into main memory?
I had a notion that nothing gets into main memory unless a page fault corresponding to a page is generated by the processor. Does the same apply for page tables too? Or is my notion incorrect.
PS: If the answer could be specific to Linux based systems, it'd be highly appreciated.
linux cpu virtual-memory
I'd like to know when is the page table of a particular process loaded in main memory by the OS? Is it when the process gets scheduled? Is the OS capable of directly loading the process page table into main memory?
I had a notion that nothing gets into main memory unless a page fault corresponding to a page is generated by the processor. Does the same apply for page tables too? Or is my notion incorrect.
PS: If the answer could be specific to Linux based systems, it'd be highly appreciated.
linux cpu virtual-memory
linux cpu virtual-memory
edited Jul 20 '16 at 5:42
rango
asked Jul 19 '16 at 19:35
rangorango
12
12
bumped to the homepage by Community♦ 4 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 4 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Since you don't mention a particular OS and processor, I'll answer this theoretically. This applies to most UNIX-like systems, but there may be minor differences.
If a process has any pages in memory, the page table needs to be in (kernel) memory. The page table needs to be available for the process to run at all, when that process is selected to run the page table has to be activated. On some machines the entire page table for a running process is actually loaded into the hardware as part of the process activation. On others the page table stays in memory and a pointer to it is loaded into a hardware register.
But, if a process gets completely swapped out and no longer has any real memory allocated to it, there is actually no need for a page table at all. When pages start getting paged in to run the program, the relevant page table can be reconstructed. Some systems to not do that optimization and keep an active page table in kernel space for every process.
But, the above is all a generalization, exact details vary widely. RTSL for more detail.
The hardware register cr3 does maintain the base address of page directory corresponding to the process. But is this address virtual/physical? Does the processor when trying to access this virtual address (if it is virtual address), give a page-fault again as a result of which page table is loaded in memory?
– rango
Jul 20 '16 at 6:11
Since I don't know the OS/CPU, I can only theorize, and that's what my answer does. If you want more detail, I suggest a look at the source.
– MAP
Jul 21 '16 at 6:10
add a comment |
On UNIX, the Page table entries of the MMU are loaded from a "page-fault" after a MMU descriptor fault hit.
In special, the "Page table" you mention does typically not exist. There is an address space description in the kernel and an MMU descriptor fault usually results in a PTE (page table entry) to be created together with the allocation of the related RAM from the kernel space.
The fact that PTEs in the MMU are a limited resource caused the creation of autoloading MMUs. For such a MMU the backup store fore the PTEs may look like a "page table".
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f296953%2fwhen-is-the-page-table-of-a-process-loaded-in-memory%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Since you don't mention a particular OS and processor, I'll answer this theoretically. This applies to most UNIX-like systems, but there may be minor differences.
If a process has any pages in memory, the page table needs to be in (kernel) memory. The page table needs to be available for the process to run at all, when that process is selected to run the page table has to be activated. On some machines the entire page table for a running process is actually loaded into the hardware as part of the process activation. On others the page table stays in memory and a pointer to it is loaded into a hardware register.
But, if a process gets completely swapped out and no longer has any real memory allocated to it, there is actually no need for a page table at all. When pages start getting paged in to run the program, the relevant page table can be reconstructed. Some systems to not do that optimization and keep an active page table in kernel space for every process.
But, the above is all a generalization, exact details vary widely. RTSL for more detail.
The hardware register cr3 does maintain the base address of page directory corresponding to the process. But is this address virtual/physical? Does the processor when trying to access this virtual address (if it is virtual address), give a page-fault again as a result of which page table is loaded in memory?
– rango
Jul 20 '16 at 6:11
Since I don't know the OS/CPU, I can only theorize, and that's what my answer does. If you want more detail, I suggest a look at the source.
– MAP
Jul 21 '16 at 6:10
add a comment |
Since you don't mention a particular OS and processor, I'll answer this theoretically. This applies to most UNIX-like systems, but there may be minor differences.
If a process has any pages in memory, the page table needs to be in (kernel) memory. The page table needs to be available for the process to run at all, when that process is selected to run the page table has to be activated. On some machines the entire page table for a running process is actually loaded into the hardware as part of the process activation. On others the page table stays in memory and a pointer to it is loaded into a hardware register.
But, if a process gets completely swapped out and no longer has any real memory allocated to it, there is actually no need for a page table at all. When pages start getting paged in to run the program, the relevant page table can be reconstructed. Some systems to not do that optimization and keep an active page table in kernel space for every process.
But, the above is all a generalization, exact details vary widely. RTSL for more detail.
The hardware register cr3 does maintain the base address of page directory corresponding to the process. But is this address virtual/physical? Does the processor when trying to access this virtual address (if it is virtual address), give a page-fault again as a result of which page table is loaded in memory?
– rango
Jul 20 '16 at 6:11
Since I don't know the OS/CPU, I can only theorize, and that's what my answer does. If you want more detail, I suggest a look at the source.
– MAP
Jul 21 '16 at 6:10
add a comment |
Since you don't mention a particular OS and processor, I'll answer this theoretically. This applies to most UNIX-like systems, but there may be minor differences.
If a process has any pages in memory, the page table needs to be in (kernel) memory. The page table needs to be available for the process to run at all, when that process is selected to run the page table has to be activated. On some machines the entire page table for a running process is actually loaded into the hardware as part of the process activation. On others the page table stays in memory and a pointer to it is loaded into a hardware register.
But, if a process gets completely swapped out and no longer has any real memory allocated to it, there is actually no need for a page table at all. When pages start getting paged in to run the program, the relevant page table can be reconstructed. Some systems to not do that optimization and keep an active page table in kernel space for every process.
But, the above is all a generalization, exact details vary widely. RTSL for more detail.
Since you don't mention a particular OS and processor, I'll answer this theoretically. This applies to most UNIX-like systems, but there may be minor differences.
If a process has any pages in memory, the page table needs to be in (kernel) memory. The page table needs to be available for the process to run at all, when that process is selected to run the page table has to be activated. On some machines the entire page table for a running process is actually loaded into the hardware as part of the process activation. On others the page table stays in memory and a pointer to it is loaded into a hardware register.
But, if a process gets completely swapped out and no longer has any real memory allocated to it, there is actually no need for a page table at all. When pages start getting paged in to run the program, the relevant page table can be reconstructed. Some systems to not do that optimization and keep an active page table in kernel space for every process.
But, the above is all a generalization, exact details vary widely. RTSL for more detail.
answered Jul 19 '16 at 21:36
MAPMAP
49528
49528
The hardware register cr3 does maintain the base address of page directory corresponding to the process. But is this address virtual/physical? Does the processor when trying to access this virtual address (if it is virtual address), give a page-fault again as a result of which page table is loaded in memory?
– rango
Jul 20 '16 at 6:11
Since I don't know the OS/CPU, I can only theorize, and that's what my answer does. If you want more detail, I suggest a look at the source.
– MAP
Jul 21 '16 at 6:10
add a comment |
The hardware register cr3 does maintain the base address of page directory corresponding to the process. But is this address virtual/physical? Does the processor when trying to access this virtual address (if it is virtual address), give a page-fault again as a result of which page table is loaded in memory?
– rango
Jul 20 '16 at 6:11
Since I don't know the OS/CPU, I can only theorize, and that's what my answer does. If you want more detail, I suggest a look at the source.
– MAP
Jul 21 '16 at 6:10
The hardware register cr3 does maintain the base address of page directory corresponding to the process. But is this address virtual/physical? Does the processor when trying to access this virtual address (if it is virtual address), give a page-fault again as a result of which page table is loaded in memory?
– rango
Jul 20 '16 at 6:11
The hardware register cr3 does maintain the base address of page directory corresponding to the process. But is this address virtual/physical? Does the processor when trying to access this virtual address (if it is virtual address), give a page-fault again as a result of which page table is loaded in memory?
– rango
Jul 20 '16 at 6:11
Since I don't know the OS/CPU, I can only theorize, and that's what my answer does. If you want more detail, I suggest a look at the source.
– MAP
Jul 21 '16 at 6:10
Since I don't know the OS/CPU, I can only theorize, and that's what my answer does. If you want more detail, I suggest a look at the source.
– MAP
Jul 21 '16 at 6:10
add a comment |
On UNIX, the Page table entries of the MMU are loaded from a "page-fault" after a MMU descriptor fault hit.
In special, the "Page table" you mention does typically not exist. There is an address space description in the kernel and an MMU descriptor fault usually results in a PTE (page table entry) to be created together with the allocation of the related RAM from the kernel space.
The fact that PTEs in the MMU are a limited resource caused the creation of autoloading MMUs. For such a MMU the backup store fore the PTEs may look like a "page table".
add a comment |
On UNIX, the Page table entries of the MMU are loaded from a "page-fault" after a MMU descriptor fault hit.
In special, the "Page table" you mention does typically not exist. There is an address space description in the kernel and an MMU descriptor fault usually results in a PTE (page table entry) to be created together with the allocation of the related RAM from the kernel space.
The fact that PTEs in the MMU are a limited resource caused the creation of autoloading MMUs. For such a MMU the backup store fore the PTEs may look like a "page table".
add a comment |
On UNIX, the Page table entries of the MMU are loaded from a "page-fault" after a MMU descriptor fault hit.
In special, the "Page table" you mention does typically not exist. There is an address space description in the kernel and an MMU descriptor fault usually results in a PTE (page table entry) to be created together with the allocation of the related RAM from the kernel space.
The fact that PTEs in the MMU are a limited resource caused the creation of autoloading MMUs. For such a MMU the backup store fore the PTEs may look like a "page table".
On UNIX, the Page table entries of the MMU are loaded from a "page-fault" after a MMU descriptor fault hit.
In special, the "Page table" you mention does typically not exist. There is an address space description in the kernel and an MMU descriptor fault usually results in a PTE (page table entry) to be created together with the allocation of the related RAM from the kernel space.
The fact that PTEs in the MMU are a limited resource caused the creation of autoloading MMUs. For such a MMU the backup store fore the PTEs may look like a "page table".
edited Jul 20 '16 at 18:45
answered Jul 19 '16 at 19:56
schilyschily
10.8k31642
10.8k31642
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f296953%2fwhen-is-the-page-table-of-a-process-loaded-in-memory%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown