Page table entries in Virtual Memory
up vote
0
down vote
favorite
I have a simple question regarding page table entries. Suppose that we are given a 32 - bit Virtual address with 4 KiB page and a physical memory size of 2^28 bits.
Since the page offset is 12 bits, we would have 2^20 page table entries which would be mapped to 2^16 physical frames. But how is it possible for 2^20 entries to map to 2^16 entries. There would run out of physical frame addresses. Suppose that the process uses the full 2^20 pages, then assuming that the whole RAM consists of memory from only this process, all the 2^16 frames in the RAM would contain this processes memory. Am i right to say that 2^4 of the page table entries would show that it maps to disk ?
Also, if the process uses only one page table, then the remaining 2^20 - 1 page table entries would be invalid ?
operating-system paging virtual-memory
add a comment |
up vote
0
down vote
favorite
I have a simple question regarding page table entries. Suppose that we are given a 32 - bit Virtual address with 4 KiB page and a physical memory size of 2^28 bits.
Since the page offset is 12 bits, we would have 2^20 page table entries which would be mapped to 2^16 physical frames. But how is it possible for 2^20 entries to map to 2^16 entries. There would run out of physical frame addresses. Suppose that the process uses the full 2^20 pages, then assuming that the whole RAM consists of memory from only this process, all the 2^16 frames in the RAM would contain this processes memory. Am i right to say that 2^4 of the page table entries would show that it maps to disk ?
Also, if the process uses only one page table, then the remaining 2^20 - 1 page table entries would be invalid ?
operating-system paging virtual-memory
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have a simple question regarding page table entries. Suppose that we are given a 32 - bit Virtual address with 4 KiB page and a physical memory size of 2^28 bits.
Since the page offset is 12 bits, we would have 2^20 page table entries which would be mapped to 2^16 physical frames. But how is it possible for 2^20 entries to map to 2^16 entries. There would run out of physical frame addresses. Suppose that the process uses the full 2^20 pages, then assuming that the whole RAM consists of memory from only this process, all the 2^16 frames in the RAM would contain this processes memory. Am i right to say that 2^4 of the page table entries would show that it maps to disk ?
Also, if the process uses only one page table, then the remaining 2^20 - 1 page table entries would be invalid ?
operating-system paging virtual-memory
I have a simple question regarding page table entries. Suppose that we are given a 32 - bit Virtual address with 4 KiB page and a physical memory size of 2^28 bits.
Since the page offset is 12 bits, we would have 2^20 page table entries which would be mapped to 2^16 physical frames. But how is it possible for 2^20 entries to map to 2^16 entries. There would run out of physical frame addresses. Suppose that the process uses the full 2^20 pages, then assuming that the whole RAM consists of memory from only this process, all the 2^16 frames in the RAM would contain this processes memory. Am i right to say that 2^4 of the page table entries would show that it maps to disk ?
Also, if the process uses only one page table, then the remaining 2^20 - 1 page table entries would be invalid ?
operating-system paging virtual-memory
operating-system paging virtual-memory
asked Nov 18 at 13:51
calveeen
6811
6811
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
1
down vote
There are a lot of assumptions in your question. To being with, you assume the page table entries are 32-bits. They could be 64 or even 128 bits.
You also assume that there are 20 bits available for indicating into page frames. Any real system is going to need some of those bits for control and protection purposes.
But how is it possible for 2^20 entries to map to 2^16 entries. There would run out of physical frame addresses.
That is the whole point of virtual memory system. Assuming you have 2^20 pages mapped to a process but only 2^16 physical pages, then not all of the process's pages are going to be mapped to page frames at the same time.
Am i right to say that 2^4 of the page table entries would show that it maps to disk ?
A rationally designed virtual memory system maintains a copy of all process pages on disk somewhere. The pages get copied from disk into memory ad mapped to the address space as needed.
Correct me if i am wrong. 1)A page table is an array of page table entries and each page table entry has to store memory for the virtual address ( 32 bits ) + permissible bits. So depending on the number of bits used for VA the page table entry could vary in size. But if we discount those permissible bits then we can assume for 32 bit VA the page table entry size is 4 bytes ? 2) So assuming all the VM is used for this process, i.e 2^20 pages are allocated, then at least 2^4 page table entries would indicate that the corresponding pages are in disc.
– calveeen
Nov 19 at 15:50
What do you mean by a VM system maintains a copy of all process pages on disk somewhere ? Wont the page table have the SWAP page number if page is in disk?
– calveeen
Nov 19 at 15:52
No, the page table does not specify where on disk the corresponding page is located—at least not directly. The Operating system has to do that mapping.
– user3344003
Nov 19 at 18:17
how about 1) and 2) ?
– calveeen
Nov 20 at 0:43
(1) You can't assume the page table entry is 32 bits. (2) all the pages would be on disk. Some might be in memory as well.
– user3344003
Nov 20 at 15:15
add a comment |
up vote
1
down vote
But how is it possible for 2^20 entries to map to 2^16 entries. There would run out of physical frame addresses.
The important thing to understand about virtual memory is that it's "virtual" - it's an illusion that doesn't actually (physically) exist. This allows the OS to do various tricks, like:
marking some/lots of virtual pages as "unused/not present" so that RAM isn't wasted when it's not needed (and so that programs get an error when they try to access something that doesn't exist - e.g.
SIGSEGV
signal).move pages between RAM and swap space to pretend that there's more RAM than there actually is. Note that this isn't limited to "swap space on disk" - e.g. it could be memory built into some kind of device (e.g. unused memory in a video card), memory that isn't in the current machine (e.g. using a network to store data in the RAM of a different computer) and it could be RAM in the same computer (e.g. if half the data can be compressed to half it's size, then "compression as swap space" would let you store 4 MiB of data in 3 MiB of RAM).
pretend RAM was allocated by mapping the same page full of zeros everywhere, and then allocate it later (if and only if the page is written to); so that you can have a large area of zeros (e.g. a program's ".bss" section) that costs almost nothing (until/unless it's written to).
pretend that a file is mapped/loaded into memory without allocating memory and without loading the file; and then allocating page/s and loading data into them if/when the data is accessed later, and also (to get more free RAM if the OS needs it for other things) freeing the memory if it wasn't modified (knowing that you can just get it from disk again later if it's accessed again later)
mapping the same pages of RAM into multiple processes. For example, if you have 10 processes that are all executing the same executable file; then the executable file might be stored in RAM once and then mapped into the virtual file system's caches plus mapped into 10 different processes.
"copy on write" tricks; where the same page of RAM is mapped into lots of processes (so any process can read from the page), and then if a process writes to the page the OS can allocate a new page and make a copy of the old page and replace the original (shared, read only) page with the new (not shared, writeable) copy.
If each virtual address space is 1 MiB, then you could have 100 processes (with 100 virtual address spaces and 1 GiB of total space) where the processes only use (on average) 512 KiB of virtual address space each, so that it looks like a total of 51200 KiB of virtual memory is being used; but the computer might only have 64 KiB of RAM where the remaining 51136 KiB of virtual memory is just trickery.
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
There are a lot of assumptions in your question. To being with, you assume the page table entries are 32-bits. They could be 64 or even 128 bits.
You also assume that there are 20 bits available for indicating into page frames. Any real system is going to need some of those bits for control and protection purposes.
But how is it possible for 2^20 entries to map to 2^16 entries. There would run out of physical frame addresses.
That is the whole point of virtual memory system. Assuming you have 2^20 pages mapped to a process but only 2^16 physical pages, then not all of the process's pages are going to be mapped to page frames at the same time.
Am i right to say that 2^4 of the page table entries would show that it maps to disk ?
A rationally designed virtual memory system maintains a copy of all process pages on disk somewhere. The pages get copied from disk into memory ad mapped to the address space as needed.
Correct me if i am wrong. 1)A page table is an array of page table entries and each page table entry has to store memory for the virtual address ( 32 bits ) + permissible bits. So depending on the number of bits used for VA the page table entry could vary in size. But if we discount those permissible bits then we can assume for 32 bit VA the page table entry size is 4 bytes ? 2) So assuming all the VM is used for this process, i.e 2^20 pages are allocated, then at least 2^4 page table entries would indicate that the corresponding pages are in disc.
– calveeen
Nov 19 at 15:50
What do you mean by a VM system maintains a copy of all process pages on disk somewhere ? Wont the page table have the SWAP page number if page is in disk?
– calveeen
Nov 19 at 15:52
No, the page table does not specify where on disk the corresponding page is located—at least not directly. The Operating system has to do that mapping.
– user3344003
Nov 19 at 18:17
how about 1) and 2) ?
– calveeen
Nov 20 at 0:43
(1) You can't assume the page table entry is 32 bits. (2) all the pages would be on disk. Some might be in memory as well.
– user3344003
Nov 20 at 15:15
add a comment |
up vote
1
down vote
There are a lot of assumptions in your question. To being with, you assume the page table entries are 32-bits. They could be 64 or even 128 bits.
You also assume that there are 20 bits available for indicating into page frames. Any real system is going to need some of those bits for control and protection purposes.
But how is it possible for 2^20 entries to map to 2^16 entries. There would run out of physical frame addresses.
That is the whole point of virtual memory system. Assuming you have 2^20 pages mapped to a process but only 2^16 physical pages, then not all of the process's pages are going to be mapped to page frames at the same time.
Am i right to say that 2^4 of the page table entries would show that it maps to disk ?
A rationally designed virtual memory system maintains a copy of all process pages on disk somewhere. The pages get copied from disk into memory ad mapped to the address space as needed.
Correct me if i am wrong. 1)A page table is an array of page table entries and each page table entry has to store memory for the virtual address ( 32 bits ) + permissible bits. So depending on the number of bits used for VA the page table entry could vary in size. But if we discount those permissible bits then we can assume for 32 bit VA the page table entry size is 4 bytes ? 2) So assuming all the VM is used for this process, i.e 2^20 pages are allocated, then at least 2^4 page table entries would indicate that the corresponding pages are in disc.
– calveeen
Nov 19 at 15:50
What do you mean by a VM system maintains a copy of all process pages on disk somewhere ? Wont the page table have the SWAP page number if page is in disk?
– calveeen
Nov 19 at 15:52
No, the page table does not specify where on disk the corresponding page is located—at least not directly. The Operating system has to do that mapping.
– user3344003
Nov 19 at 18:17
how about 1) and 2) ?
– calveeen
Nov 20 at 0:43
(1) You can't assume the page table entry is 32 bits. (2) all the pages would be on disk. Some might be in memory as well.
– user3344003
Nov 20 at 15:15
add a comment |
up vote
1
down vote
up vote
1
down vote
There are a lot of assumptions in your question. To being with, you assume the page table entries are 32-bits. They could be 64 or even 128 bits.
You also assume that there are 20 bits available for indicating into page frames. Any real system is going to need some of those bits for control and protection purposes.
But how is it possible for 2^20 entries to map to 2^16 entries. There would run out of physical frame addresses.
That is the whole point of virtual memory system. Assuming you have 2^20 pages mapped to a process but only 2^16 physical pages, then not all of the process's pages are going to be mapped to page frames at the same time.
Am i right to say that 2^4 of the page table entries would show that it maps to disk ?
A rationally designed virtual memory system maintains a copy of all process pages on disk somewhere. The pages get copied from disk into memory ad mapped to the address space as needed.
There are a lot of assumptions in your question. To being with, you assume the page table entries are 32-bits. They could be 64 or even 128 bits.
You also assume that there are 20 bits available for indicating into page frames. Any real system is going to need some of those bits for control and protection purposes.
But how is it possible for 2^20 entries to map to 2^16 entries. There would run out of physical frame addresses.
That is the whole point of virtual memory system. Assuming you have 2^20 pages mapped to a process but only 2^16 physical pages, then not all of the process's pages are going to be mapped to page frames at the same time.
Am i right to say that 2^4 of the page table entries would show that it maps to disk ?
A rationally designed virtual memory system maintains a copy of all process pages on disk somewhere. The pages get copied from disk into memory ad mapped to the address space as needed.
answered Nov 19 at 15:18
user3344003
14.2k31437
14.2k31437
Correct me if i am wrong. 1)A page table is an array of page table entries and each page table entry has to store memory for the virtual address ( 32 bits ) + permissible bits. So depending on the number of bits used for VA the page table entry could vary in size. But if we discount those permissible bits then we can assume for 32 bit VA the page table entry size is 4 bytes ? 2) So assuming all the VM is used for this process, i.e 2^20 pages are allocated, then at least 2^4 page table entries would indicate that the corresponding pages are in disc.
– calveeen
Nov 19 at 15:50
What do you mean by a VM system maintains a copy of all process pages on disk somewhere ? Wont the page table have the SWAP page number if page is in disk?
– calveeen
Nov 19 at 15:52
No, the page table does not specify where on disk the corresponding page is located—at least not directly. The Operating system has to do that mapping.
– user3344003
Nov 19 at 18:17
how about 1) and 2) ?
– calveeen
Nov 20 at 0:43
(1) You can't assume the page table entry is 32 bits. (2) all the pages would be on disk. Some might be in memory as well.
– user3344003
Nov 20 at 15:15
add a comment |
Correct me if i am wrong. 1)A page table is an array of page table entries and each page table entry has to store memory for the virtual address ( 32 bits ) + permissible bits. So depending on the number of bits used for VA the page table entry could vary in size. But if we discount those permissible bits then we can assume for 32 bit VA the page table entry size is 4 bytes ? 2) So assuming all the VM is used for this process, i.e 2^20 pages are allocated, then at least 2^4 page table entries would indicate that the corresponding pages are in disc.
– calveeen
Nov 19 at 15:50
What do you mean by a VM system maintains a copy of all process pages on disk somewhere ? Wont the page table have the SWAP page number if page is in disk?
– calveeen
Nov 19 at 15:52
No, the page table does not specify where on disk the corresponding page is located—at least not directly. The Operating system has to do that mapping.
– user3344003
Nov 19 at 18:17
how about 1) and 2) ?
– calveeen
Nov 20 at 0:43
(1) You can't assume the page table entry is 32 bits. (2) all the pages would be on disk. Some might be in memory as well.
– user3344003
Nov 20 at 15:15
Correct me if i am wrong. 1)A page table is an array of page table entries and each page table entry has to store memory for the virtual address ( 32 bits ) + permissible bits. So depending on the number of bits used for VA the page table entry could vary in size. But if we discount those permissible bits then we can assume for 32 bit VA the page table entry size is 4 bytes ? 2) So assuming all the VM is used for this process, i.e 2^20 pages are allocated, then at least 2^4 page table entries would indicate that the corresponding pages are in disc.
– calveeen
Nov 19 at 15:50
Correct me if i am wrong. 1)A page table is an array of page table entries and each page table entry has to store memory for the virtual address ( 32 bits ) + permissible bits. So depending on the number of bits used for VA the page table entry could vary in size. But if we discount those permissible bits then we can assume for 32 bit VA the page table entry size is 4 bytes ? 2) So assuming all the VM is used for this process, i.e 2^20 pages are allocated, then at least 2^4 page table entries would indicate that the corresponding pages are in disc.
– calveeen
Nov 19 at 15:50
What do you mean by a VM system maintains a copy of all process pages on disk somewhere ? Wont the page table have the SWAP page number if page is in disk?
– calveeen
Nov 19 at 15:52
What do you mean by a VM system maintains a copy of all process pages on disk somewhere ? Wont the page table have the SWAP page number if page is in disk?
– calveeen
Nov 19 at 15:52
No, the page table does not specify where on disk the corresponding page is located—at least not directly. The Operating system has to do that mapping.
– user3344003
Nov 19 at 18:17
No, the page table does not specify where on disk the corresponding page is located—at least not directly. The Operating system has to do that mapping.
– user3344003
Nov 19 at 18:17
how about 1) and 2) ?
– calveeen
Nov 20 at 0:43
how about 1) and 2) ?
– calveeen
Nov 20 at 0:43
(1) You can't assume the page table entry is 32 bits. (2) all the pages would be on disk. Some might be in memory as well.
– user3344003
Nov 20 at 15:15
(1) You can't assume the page table entry is 32 bits. (2) all the pages would be on disk. Some might be in memory as well.
– user3344003
Nov 20 at 15:15
add a comment |
up vote
1
down vote
But how is it possible for 2^20 entries to map to 2^16 entries. There would run out of physical frame addresses.
The important thing to understand about virtual memory is that it's "virtual" - it's an illusion that doesn't actually (physically) exist. This allows the OS to do various tricks, like:
marking some/lots of virtual pages as "unused/not present" so that RAM isn't wasted when it's not needed (and so that programs get an error when they try to access something that doesn't exist - e.g.
SIGSEGV
signal).move pages between RAM and swap space to pretend that there's more RAM than there actually is. Note that this isn't limited to "swap space on disk" - e.g. it could be memory built into some kind of device (e.g. unused memory in a video card), memory that isn't in the current machine (e.g. using a network to store data in the RAM of a different computer) and it could be RAM in the same computer (e.g. if half the data can be compressed to half it's size, then "compression as swap space" would let you store 4 MiB of data in 3 MiB of RAM).
pretend RAM was allocated by mapping the same page full of zeros everywhere, and then allocate it later (if and only if the page is written to); so that you can have a large area of zeros (e.g. a program's ".bss" section) that costs almost nothing (until/unless it's written to).
pretend that a file is mapped/loaded into memory without allocating memory and without loading the file; and then allocating page/s and loading data into them if/when the data is accessed later, and also (to get more free RAM if the OS needs it for other things) freeing the memory if it wasn't modified (knowing that you can just get it from disk again later if it's accessed again later)
mapping the same pages of RAM into multiple processes. For example, if you have 10 processes that are all executing the same executable file; then the executable file might be stored in RAM once and then mapped into the virtual file system's caches plus mapped into 10 different processes.
"copy on write" tricks; where the same page of RAM is mapped into lots of processes (so any process can read from the page), and then if a process writes to the page the OS can allocate a new page and make a copy of the old page and replace the original (shared, read only) page with the new (not shared, writeable) copy.
If each virtual address space is 1 MiB, then you could have 100 processes (with 100 virtual address spaces and 1 GiB of total space) where the processes only use (on average) 512 KiB of virtual address space each, so that it looks like a total of 51200 KiB of virtual memory is being used; but the computer might only have 64 KiB of RAM where the remaining 51136 KiB of virtual memory is just trickery.
add a comment |
up vote
1
down vote
But how is it possible for 2^20 entries to map to 2^16 entries. There would run out of physical frame addresses.
The important thing to understand about virtual memory is that it's "virtual" - it's an illusion that doesn't actually (physically) exist. This allows the OS to do various tricks, like:
marking some/lots of virtual pages as "unused/not present" so that RAM isn't wasted when it's not needed (and so that programs get an error when they try to access something that doesn't exist - e.g.
SIGSEGV
signal).move pages between RAM and swap space to pretend that there's more RAM than there actually is. Note that this isn't limited to "swap space on disk" - e.g. it could be memory built into some kind of device (e.g. unused memory in a video card), memory that isn't in the current machine (e.g. using a network to store data in the RAM of a different computer) and it could be RAM in the same computer (e.g. if half the data can be compressed to half it's size, then "compression as swap space" would let you store 4 MiB of data in 3 MiB of RAM).
pretend RAM was allocated by mapping the same page full of zeros everywhere, and then allocate it later (if and only if the page is written to); so that you can have a large area of zeros (e.g. a program's ".bss" section) that costs almost nothing (until/unless it's written to).
pretend that a file is mapped/loaded into memory without allocating memory and without loading the file; and then allocating page/s and loading data into them if/when the data is accessed later, and also (to get more free RAM if the OS needs it for other things) freeing the memory if it wasn't modified (knowing that you can just get it from disk again later if it's accessed again later)
mapping the same pages of RAM into multiple processes. For example, if you have 10 processes that are all executing the same executable file; then the executable file might be stored in RAM once and then mapped into the virtual file system's caches plus mapped into 10 different processes.
"copy on write" tricks; where the same page of RAM is mapped into lots of processes (so any process can read from the page), and then if a process writes to the page the OS can allocate a new page and make a copy of the old page and replace the original (shared, read only) page with the new (not shared, writeable) copy.
If each virtual address space is 1 MiB, then you could have 100 processes (with 100 virtual address spaces and 1 GiB of total space) where the processes only use (on average) 512 KiB of virtual address space each, so that it looks like a total of 51200 KiB of virtual memory is being used; but the computer might only have 64 KiB of RAM where the remaining 51136 KiB of virtual memory is just trickery.
add a comment |
up vote
1
down vote
up vote
1
down vote
But how is it possible for 2^20 entries to map to 2^16 entries. There would run out of physical frame addresses.
The important thing to understand about virtual memory is that it's "virtual" - it's an illusion that doesn't actually (physically) exist. This allows the OS to do various tricks, like:
marking some/lots of virtual pages as "unused/not present" so that RAM isn't wasted when it's not needed (and so that programs get an error when they try to access something that doesn't exist - e.g.
SIGSEGV
signal).move pages between RAM and swap space to pretend that there's more RAM than there actually is. Note that this isn't limited to "swap space on disk" - e.g. it could be memory built into some kind of device (e.g. unused memory in a video card), memory that isn't in the current machine (e.g. using a network to store data in the RAM of a different computer) and it could be RAM in the same computer (e.g. if half the data can be compressed to half it's size, then "compression as swap space" would let you store 4 MiB of data in 3 MiB of RAM).
pretend RAM was allocated by mapping the same page full of zeros everywhere, and then allocate it later (if and only if the page is written to); so that you can have a large area of zeros (e.g. a program's ".bss" section) that costs almost nothing (until/unless it's written to).
pretend that a file is mapped/loaded into memory without allocating memory and without loading the file; and then allocating page/s and loading data into them if/when the data is accessed later, and also (to get more free RAM if the OS needs it for other things) freeing the memory if it wasn't modified (knowing that you can just get it from disk again later if it's accessed again later)
mapping the same pages of RAM into multiple processes. For example, if you have 10 processes that are all executing the same executable file; then the executable file might be stored in RAM once and then mapped into the virtual file system's caches plus mapped into 10 different processes.
"copy on write" tricks; where the same page of RAM is mapped into lots of processes (so any process can read from the page), and then if a process writes to the page the OS can allocate a new page and make a copy of the old page and replace the original (shared, read only) page with the new (not shared, writeable) copy.
If each virtual address space is 1 MiB, then you could have 100 processes (with 100 virtual address spaces and 1 GiB of total space) where the processes only use (on average) 512 KiB of virtual address space each, so that it looks like a total of 51200 KiB of virtual memory is being used; but the computer might only have 64 KiB of RAM where the remaining 51136 KiB of virtual memory is just trickery.
But how is it possible for 2^20 entries to map to 2^16 entries. There would run out of physical frame addresses.
The important thing to understand about virtual memory is that it's "virtual" - it's an illusion that doesn't actually (physically) exist. This allows the OS to do various tricks, like:
marking some/lots of virtual pages as "unused/not present" so that RAM isn't wasted when it's not needed (and so that programs get an error when they try to access something that doesn't exist - e.g.
SIGSEGV
signal).move pages between RAM and swap space to pretend that there's more RAM than there actually is. Note that this isn't limited to "swap space on disk" - e.g. it could be memory built into some kind of device (e.g. unused memory in a video card), memory that isn't in the current machine (e.g. using a network to store data in the RAM of a different computer) and it could be RAM in the same computer (e.g. if half the data can be compressed to half it's size, then "compression as swap space" would let you store 4 MiB of data in 3 MiB of RAM).
pretend RAM was allocated by mapping the same page full of zeros everywhere, and then allocate it later (if and only if the page is written to); so that you can have a large area of zeros (e.g. a program's ".bss" section) that costs almost nothing (until/unless it's written to).
pretend that a file is mapped/loaded into memory without allocating memory and without loading the file; and then allocating page/s and loading data into them if/when the data is accessed later, and also (to get more free RAM if the OS needs it for other things) freeing the memory if it wasn't modified (knowing that you can just get it from disk again later if it's accessed again later)
mapping the same pages of RAM into multiple processes. For example, if you have 10 processes that are all executing the same executable file; then the executable file might be stored in RAM once and then mapped into the virtual file system's caches plus mapped into 10 different processes.
"copy on write" tricks; where the same page of RAM is mapped into lots of processes (so any process can read from the page), and then if a process writes to the page the OS can allocate a new page and make a copy of the old page and replace the original (shared, read only) page with the new (not shared, writeable) copy.
If each virtual address space is 1 MiB, then you could have 100 processes (with 100 virtual address spaces and 1 GiB of total space) where the processes only use (on average) 512 KiB of virtual address space each, so that it looks like a total of 51200 KiB of virtual memory is being used; but the computer might only have 64 KiB of RAM where the remaining 51136 KiB of virtual memory is just trickery.
answered Nov 19 at 19:14
Brendan
11.8k1230
11.8k1230
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- 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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2fstackoverflow.com%2fquestions%2f53361627%2fpage-table-entries-in-virtual-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