This is an interview question. I am writing all the details the interviewer gave me. The question is:-
A system has a memory of 1GB. A process requires only 1MB of memory. Assuming no other processes are running in memory, will the OS provide virtual address translation for this process or give the entire 1MB of physical space ?
Assuming this is a virtual memory system and at the risk of gross oversimplification:
Such system would use address translation for any processes, even if only one is running.
Such a system is unlikely to provide the 1MB of memory until the process accesses that much memory. That is, the system will only allocate physical pages on demand.
Related
Is Memory address translation only useful when the total size of virtual memory
(summed over all processes) needs to be larger than physical memory?
Basically, the size of virtual memory depends on what you call "virtual memory". If you call virtual memory the virtual memory of one process then virtual memory has the same size than physical memory. If you call virtual memory the whole virtual memory of all processes than virtual memory can (technically) have an infinite size. This is because every process can have a whole address space. The virtual address space of one process cannot be bigger than physical memory because the processor has limited bits to address this memory. In modern long mode the processor has only 48 bits to address RAM at the byte level. This gives a very big amount of RAM but most systems will have 8GB to 32GB.
Technically on a 8GB RAM computer, every process could have 8GB allocated. I say technically because eventually, the computer will constantly be removing page frames from RAM and that will put too much overhead on the OS and on the computer which will make your system freeze. In the end, the size of the sum of the virtual memory of every process is limited by the capacity of your system (and OS) to have an efficient page swapping algorithm (and on your willingness to have a slow system).
Now to answer your question, paging (virtual memory) is used also to avoid fragmentation and for securing the system. With the old segmentation model, fragmentation was an issue because you had to run a complex algorithm to determine which part of memory a process gets. With paging, the smallest granularity of memory is 4KB. This makes everything much easier because a small process just gets a 4KB page and the process can work in that page the way it wants. While a bigger process will get several pages and can allocate more pages by doing a system call. There is still the issue of external fragmentation but it is mostly due to latency of accessing high memory vs low memory. Basically, paging solves the issue of external fragmentation because a process can get a page anywhere (where it's available) and it will not make a difference (except for high vs low memory). There is still the issue of internal fragmentation with paging.
Paging also secures the system. With segmentation you had several levels of ring protection. With paging you have only user or supervisor. With segmentation, the memory is not well protected because one process can access the memory of another process in the same segment. With paging, there are 2 different protections. The first protection is the ring itself (user vs supervisor) the second are the page tables. The page tables isolate one process from another because the memory accesses are translated to other positions in RAM. It is the job of the OS to fill the page tables properly so that one process doesn't have access to the physical memory allocated to another process. The user vs supervisor bit in the page tables, prevent one process from accessing the kernel except via a system call interface (the instruction syscall in assembly for x86).
I have an exam tomorrow on virtual memory address translation and I'm rather confused on this topic. I know the CPU will generate a virtual address to then access a physical address. So if we have a system with 32 bit virtual addresses, and 64 bit physical addresses, then the pointers for user level processes I'm guessing will be 8 bytes.
My logic is because the virtual address is being translated to the physical address, so this number will always be coming from the physical address.
No, user-space processes work only with virtual addresses (32-bit in your example).
The memory they "see" is their own private virtual address space. (They can make system calls like mmap and munmap to request that pages in that address-space be backed by files, or by anonymous RAM like for C malloc.) But they don't know anything about where in physical memory those pages are located.
The OS can even "fake it" by paging out some of their pages to swap space / page file, and handling the page fault if the process touches such a page by doing I/O to bring it back in and then waking up the process to rerun the load or store instruction that page faulted.
Hardware translates virtual addresses to physical addresses on every memory access. To make this fast, a TLB caches recently-used translations. On a TLB miss, hardware does a "page walk", reading the page tables to find the right virtual page->physical page translation.
The OS manages the page tables, choosing any physical page as "backing" for a virtual page.
Physical addresses wider than virtual?
Under a multi-tasking OS, multiple processes can be running. Each one has its own 32-bit (4GiB) virtual address space.
The size of physical address space limits how much RAM you can put in a machine total, and can be different from how much any single process can use at once. Changing page tables is faster than reading from disk, so even if it can't all be mapped at once, a kernel can still make use of lots of physical RAM for pagecache (cache of file contents from disk).
More importantly, multiple processes can be running, each with their own up-to-4GiB of virtual address space backed by physical memory, up to the amount of physical RAM in the system. On a CPU with multiple cores, these can be running simultaneously, truly allowing simultaneous use of more than 4GB of RAM. But not by any single process.
x86 is a good example here: Running an x86-64 kernel with 32-bit user-space gives us pretty much the situation you describe. (A 64-bit kernel can use 64-bit virtual addresses, but nevermind that, just look at user-space.)
You can have several processes each using about 4GiB of physical RAM.
The x86-64 page-table format has room for physical addresses as wide as 52-bit, although current HW doesn't use that many. (Only as wide as the amount of RAM it actually supports attaching. Saves bits in the TLBs, and other parts of the CPU). https://en.wikipedia.org/wiki/X86-64#Architectural_features
Before x86-64, 32-bit x86 kernels could use the same page-table format but with 36-bit physical addresses, on CPUs from Pentium Pro and later.
https://en.wikipedia.org/wiki/Physical_Address_Extension. That allowed up to 64GB of physical RAM. (A 32-bit kernel would typically reserve 1 or 2GB of virtual address space for itself so each process could really only use up to 3 or 2GB, but it's the same idea. Not a problem for 32-bit user-space under a 64-bit kernel though, so that made a simpler example.)
Virtual addresses are visible to user-level processes. They never should never see the physical address. So if virtual addresses are 32-bit, pointers in user-level processes are also 32-bit, i.e. 4 bytes.
The system/kernel then needs to do the translation somehow. It will know the virtual address and must translate it to the physical address, so it will eventually have a physical pointer, 64-bit = 8 byte. But once again, this address/pointer are for "internal use" only.
In practice though, you will have virtual and physical addresses of the same size, matching the word size of the CPU and its architecture (x86 vs x86_64). A virtual to pyhsicial translation will normally need to happen in a page fault, which happens when a user-level process attempts to access memory that is not loaded. To access it in the first place, it needs to have e.g. dereferenced a pointer pointing to that address, which would be done with a memory access instruction of the particular CPU architecture, which is done with word-sized addresses.
The programmer will only see virtual addresses. The physical address space is opaque to the programmer and the user. Therefore, size of a pointer is dependent on the size of the virtual address. In the particular case you have given, the maximum amount of memory your system can consume is dictated by your virtual address space. This is why 32-bit OS on 64-bit hardware is limited to a maximum of 4 gigs of memory. But, in the case of a 64-bit virtual address, even if we have insufficient RAM, we can offload some of the pages to the secondary storage to give the illusion that we have more RAM available. In the case, the page is located in the secondary memory, a page fault occurs and the page is transferred to RAM.
Edit : As Peter said in the comments, the virtual address limit affects the maximum memory a Process can consume.
I know that user program generates logical addresses.Suppose there is a small code snippet in C .When address is printed,the addresses are virtual addresses.My question is where are those addresses fetched from?where exactly do the allocated values and variables stay?At main memory or secondary memory?If main memory then why there is physical address?
User mode programs only see logical addresses. Only the operating system (kernel mode) sees physical memory.
My question is where are those addresses fetched from?
Those are the logical addresses assigned by the program loader ad linker.
where exactly do the allocated values and variables stay?At main memory or secondary memory?
In a virtual memory system, it may be in main memory or secondary storage.
If main memory then why there is physical address?
It is a logical address that is mapped to a physical address using page tables.
I am kind of new to the computer architecture and Operating System,
but I will try to answer as much as I can. As far as I have
understood about the logical address (Which I still have trouble
understanding, about where it is fetched from or where it is stored.
I mean these addresses (numbers) gotta be stored somewhere,
otherwise CPU can't generate it by itself, right?), these addresses
are assigned by CPU or a processor and depends on the CPU
architecture. Each process is assigned a virtual/logical
address. And this logical address is translated to physical address
by Memory Management Unit of CPU (MMU).
Where exactly do the allocated values and variables stay? As user3344003 said, it may be in main memory or secondary storage.
If main memory then why there is physical address? The reason lies
in the concept of Virtual Memory. Each process has its own virtual
address and a page table. Process's logical address are mapped
through this page table to the Physical memory (RAM). Whatever that
logical address is, it gets mapped to Physical address. If the
Physical memory gets full, then OS evicts some of the less used
or unused process to Secondary storage and puts the needed process
in the RAM. That way multiple process can run at the same time.
Every process assumes that they have all the space in RAM just for
themselves. If not for virtual memory, then physical memory would be
full and process might crash and may shut down the OS as well.
Hope it helps. I am still learning, if my understanding about Logical address and virtual memory is wrong then Please comment.
I'm studying OS and I have a doubt about physical and logical addresses.
If logical addresses do not exist in real and are only used to indicate physical addresses, why do we use logical addresses at all? Why not directly physical address?
Thanks in advance!
One good example of why an operating system uses a logical address is the concept of virtual memory. For example, a process can be running in Windows which requires 100MB of RAM to execute. Without virtual memory, if this amount of RAM were not available, the process could not run. With virtual memory, the Windows OS can tell the process that the memory it needs is available. However, the OS cannot expose 100MB of physical memory because it does not exist. Instead, the OS will expose 100MB of logical memory. Some or all of this memory may not map to a physical address. Instead, it might map to disk or another location.
Another reason is fragmentation.
Lets say you have 100 MB of memory and the first three processes need 20 MB each. You give them the memory they want, they run and then the second one terminates. You are left with 60 MB of free memory, but any process that wants a sequential address space of 50 MB can't have it.
Using logical addresses gives you that ability.
One of the major benefits of using logical addresses (and in fact, similar thinking is true for most naming abstractions such as domain names in the networking context, file descriptors, etc.) is that programs can be written in a way that is agnostic to the actual layout of physical memory. That is, you can write your program such that data is stored in say, address 0xdeadbeef (this is a logical address), and your program would work just fine (the MMU or a boot loader that performs binary translation would convert the logical address into an appropriate physical address at run-time or at boot time).
In the above scenario, if your program were written to use physical addresses from the get go, you would run the risk of running into conflicts with other processes that use the same address to store data (e.g., other instances of your program).
What does the virtual memory space size depend on? Does it depend on the RAM or on the architecture or something else.
Basically it depends on the architecture (32bit 64bit and so...).
This is a very simplistic explanation of things, but so called "architecture" limits size of the virtual address space. For example, 32bit architecture will enable to address 2^31 memory addresses.
The size of the RAM will limit the amount of physical memory that can be used, but not the virtual address space. (potentially the Hard-drive can be used to extend the available physical memory)
Anyway I recommend to read the wiki page on virtual memory
Very simply, virtual memory is just a way of letting your software use more memory addresses than there is actual physical memory, such that when the data being access isn't already hosted in physical memory it's transparently read in from disk, and when some more physical memory is needed to do things like that some of the current content of physical memory is temporarily written or "swapped" out to disk (e.g. the least-recently used memory). In other words, some of the physical memory becomes a kind of cache for a larger virtual memory space including hard disk.