If a computer architecture is guaranteed to have 4GB of main memory, do we need to hardware for virtual memory handling ? In other words, can we do away with VM if 32 bit architecture has 4GB of main memory ?
If there is no VM, we can certainly save some overhead of translation of virtual address into physical address & page table handling. Obviously, we still need some protection mechanisms.
I just want to know what others in this forum think on this issue.
Tejas Kokje
virtual memory on a 4GB main memory system
-
- Posts: 11
- Joined: Thu Jul 03, 2008 12:37 am
Re: virtual memory on a 4GB main memory system
It would increase performance because you would not have to worry about invalidating page tables, and depending on the processor and how it caches data you could also get performance increases by not invalidating data in the cache when changing tables and directories.
The only drawback is swap space. By using virtual memory you could give each program _almost_ 4GB of memory. I say almost because the kernel and other things have to sit somewhere in memory. The swap space is where you write out pages from memory to disk and mark them as not present for that process. So the next time you switch to it and it accesses something that is not there you can load it back up. Also cold pages which may be data that the process rarely uses can be swapped out to disk and this gives more space for other processes. That is hard to do with out virtual memory providing the page fault mechanism.
The only drawback is swap space. By using virtual memory you could give each program _almost_ 4GB of memory. I say almost because the kernel and other things have to sit somewhere in memory. The swap space is where you write out pages from memory to disk and mark them as not present for that process. So the next time you switch to it and it accesses something that is not there you can load it back up. Also cold pages which may be data that the process rarely uses can be swapped out to disk and this gives more space for other processes. That is hard to do with out virtual memory providing the page fault mechanism.
-
- Posts: 11
- Joined: Thu Jul 03, 2008 12:37 am
Re: virtual memory on a 4GB main memory system
I don't get it. If you have 4 GB of physical memory with no VM, doesn't each process get whole 4GB minus kernel memory ?? Then when kernel context switches, you can swap that whole process out and give 4GB to new ready_to_run process. Memory can be divided into blocks and you can selectively load blocks in memory when process is context switched in again.kmcguire wrote: The only drawback is swap space. By using virtual memory you could give each program _almost_ 4GB of memory. I say almost because the kernel and other things have to sit somewhere in memory. The swap space is where you write out pages from memory to disk and mark them as not present for that process. So the next time you switch to it and it accesses something that is not there you can load it back up. Also cold pages which may be data that the process rarely uses can be swapped out to disk and this gives more space for other processes. That is hard to do with out virtual memory providing the page fault mechanism.
Tejas Kokje
Re: virtual memory on a 4GB main memory system
Isn't what you describe pretty much what memory swapping is? Memory is divided into blocks already and are selectively loaded on and off disk as required.
Can you clarify your position, as your original post seems to be talking about the redundancy of virtual address translation.
Can you clarify your position, as your original post seems to be talking about the redundancy of virtual address translation.
The cake is a lie | rackbits.com
-
- Posts: 11
- Joined: Thu Jul 03, 2008 12:37 am
Re: virtual memory on a 4GB main memory system
Yes, my position still remains same. Why do we need translation in 4GB physical memory system. Swapping can still continue to work as it is.ucosty wrote:Isn't what you describe pretty much what memory swapping is? Memory is divided into blocks already and are selectively loaded on and off disk as required.
Can you clarify your position, as your original post seems to be talking about the redundancy of virtual address translation.
I was just responding to kcmguire's comment.
Tejas Kokje
Re: virtual memory on a 4GB main memory system
You could swap out the process each time but it would be inefficient and wouldn't work with multi-core at any rate. If you only swap out pages as needed (for instance when multiple processes are together using more than 4GB of memory) then you can have fragmentation problems. Or if you just swap out the page (in the old process) that you're going to allocate for the active process then you can have the problem of hot pages continually being swapped to & from disk.binarysemaphore wrote: I don't get it. If you have 4 GB of physical memory with no VM, doesn't each process get whole 4GB minus kernel memory ?? Then when kernel context switches, you can swap that whole process out and give 4GB to new ready_to_run process. Memory can be divided into blocks and you can selectively load blocks in memory when process is context switched in again.
Re: virtual memory on a 4GB main memory system
binarysemaphore wrote:Yes, my position still remains same. Why do we need translation in 4GB physical memory system. Swapping can still continue to work as it is.ucosty wrote:Isn't what you describe pretty much what memory swapping is? Memory is divided into blocks already and are selectively loaded on and off disk as required.
Can you clarify your position, as your original post seems to be talking about the redundancy of virtual address translation.
I was just responding to kcmguire's comment.
Tejas Kokje
What is the point of swapping without address translation? Without address translation no two programs would be able to use the same block of memory unless you swap *all* of the memory of a process to disk at each process switch. That would be so inefficient and slow.
The cake is a lie | rackbits.com
Re: virtual memory on a 4GB main memory system
@binarysemaphore:
You are confusing two separate meanings for "swapping" here. You are assuming a "virtual memory swapping" ability, while saying that you will not be using VM. kmcguire is right.
When your scheduler "swaps out" a running job, that entire job remains in memory. "Swapping out" in this case simply means "changing EIP so that a different program in a different part of memory is running." Without virtual memory, all your programs would need to be coded using Position Independent Coding, all of the active jobs would all be loaded in memory all at the same time, and no, they would all have significantly less than 4G of space to run in.
Virtual memory is what completely frees up the computer's memory between task switches. It enables many running jobs to all use any particular "memory address" at the same time without conflicting with each other -- even if all the jobs remain loaded together in physical memory -- because memory addresses are translated differently for each running job.
You are confusing two separate meanings for "swapping" here. You are assuming a "virtual memory swapping" ability, while saying that you will not be using VM. kmcguire is right.
When your scheduler "swaps out" a running job, that entire job remains in memory. "Swapping out" in this case simply means "changing EIP so that a different program in a different part of memory is running." Without virtual memory, all your programs would need to be coded using Position Independent Coding, all of the active jobs would all be loaded in memory all at the same time, and no, they would all have significantly less than 4G of space to run in.
Virtual memory is what completely frees up the computer's memory between task switches. It enables many running jobs to all use any particular "memory address" at the same time without conflicting with each other -- even if all the jobs remain loaded together in physical memory -- because memory addresses are translated differently for each running job.