• 0
name Punditsdkoslkdosdkoskdo

What does the Kernel Virtual Memory of each process contain?

When say 3 programs (executables) are loaded into memory the layout might look something like this:

alt text

I've following questions:

  1. Is the concept of Virtual Memory limited to user processes? Because, I am wondering where does the Operating System Kernel, Drivers live? How is its memory layout? I want to know more about kernel side memory. I know its operating system specific make your choice (windows/linux).

  2. Is the concept of Virtual Memory per process basis? I mean is it correct for me to say 4GB of process1 + 4GB of process2 + 4GB of process3 = 12GB of virtual memory (for all processes). This does't sound right. Or from a total of 4GB space 1GB is taken by kernel & rest 3GB is shared b/w all processes.

  3. They say, on a 32 bit machine in a 4GB address space. Half of it (or more recently 1GB) is occupied by kernel. I can see in this diagram that "Kernel Virtual memory" is occupying 0xc0000000 - 0xffffffff (= 1 GB). Are they talking about this? or is it something else? Just want to confirm.

  4. What exactly does the Kernel Virtual Memory of each of these processes contain? What is its layout?

  5. When we do IPC we talk about shared memory. I don't see any memory shared between these processes. Where does it live?

  6. Resources (files, registries in windows) are global to all processes. So, the resource/file handle table must be in some global space. Which area would that be in?

  7. Where can I know more about this kernel side stuff.

To answer your question, you need to understand more about Kernel and the techniques it employs to manage resources (CPU, memory, ...) and to provide elegant abstraction to the Application programs.

Firstly i want to make it clear that 'Virtual Memory' is a memory management technique employed by modern operating systems; which provides various benefits like process isolation, there by protection, allows multiple programs to run together, allows programs whose size is larger than the physical memory present in the system. Under this technique, again there are two terms 'Virtual Memory' and 'Virtual Address Space'; which are not same, but still closely related. (You would be wondering how is Virtual memory is both a technique as well as a concept under it, but yes that is correct and you will understand that below)

In computer science, the word 'memory' has 2 meanings. First one, is for something that you can use to store data (registers, cache, RAM, ROM, HDD, etc). Second one, is for synonymous with primary memory (i.e., RAM). When you replace word by word, 'Virtual Memory' is nothing but 'Virtual RAM'. That is the total amount of space available at all times in the system, in which the programs are loaded for execution. So this is nothing but Physical RAM memory + the swap memory on the secondary storage allocated by the kernel. So if you have 2GB of RAM and 4 GB of swap space set aside by kernel at installation time, then the Virtual memory of your system is 6GB. I am not going to explain more on the swap memory here, as this would deviate more from the topic.

Moving on to Virtual Address Space. So to understand this you need to tune your mind a bit. As the name itself "Virtual" says, the address space is not present in reality! This is just an illusion created by kernel to the application programmers (to achieve lot of benefits as i mentioned in paragraph 2) So each process is given a separate virtual address space by the kernel. (If there was no Kernel in the system and had you run your application program on the hardware then it would have used the physical address space, i.e., RAM as its address space) So on a machine with 32 bit address registers, the kernel could provide a virtual address space of 2^32 = 4GB for each process. (So this virtual address space range changes with the HW architecture. Latest processors have 48 bit address registers so they can provide a virtual address space of 2^48 = 256TB) And importantly this virtual address space is just in the air!! You would be thinking now, if it is just in the air, how can the code, data of the process be even executed. Yes, this need to be mapped to physical memory. How it is mapped with the physical memory is managed by kernel using the concept called paging. So now you can see how the kernel has achieved process isolation using virtual address space. So the address that each process can generate is between 0 to 4GB (assuming the system has 32 bit address register for simplicity sake), so which is within its entirety. And it knows nothing about any other process running in the system. So it is like each process is packed in a separate space.

So kernel code is also like another process/entity. So if kernel were to reside in an entirely different address space. Then there was no means for an application programs to interact with kernel. If application cant communicate with kernel and kernel cant communicate with application then there is no usefulness of the kernel to drive the system. So the question now is - How to make application processes to interact with the kernel? An option would be - If kernel code was present in the virtual address space of the application process then they could interact with each other. That's the reason why kernel code is present in each of the process' virtual address space because every process need to communicate with the kernel. Don't worry kernel code is not physically duplicated for each process. As i mentioned earlier VAS is just an illusion, so there will be just one copy of kernel code present in physical memory and it will be reference by all of the virtual address spaces (through paging). In case of linux, kernel would be placed on the upper address space between C000 0000 to FFFF FFFF (ie the reason 1GB is reserved for kernel in VAS) and rest 3GB (from 0000 0000 to BFFF FFFF) is allowed for the application program to use. The virtual address space where kernel resides is known as kernel space and where the application program resides is called user space. If you had carefully observed, then you would have come up with the question that if both application code and kernel code is residing in the same virtual address space, and since the kernel resides in a well pre-defined address location then is it not possible for the application code to corrupt the kernel code! Oops, at first it looks to be possible, but it can't. Reason being - this is protected using the help of HW. There will be flag on the processor which indicates whether the execution mode is SUPERVISOR MODE or USER MODE. Kernel space code should execute in SUPERVISOR MODE (setting that flag appropriately) and user space code should execute in USER MODE. So if you are in USER MODE and tries to access/modify code in kernel space then an exception is thrown! (processor gets to know it based on the address the instruction is trying to access. If it is higher than C000 0000 then it can easy detect it is trying to access kernel space code and the current execution mode doesn't have appropriate permission, since the flag is set with USER MODE permission). Just a note: In SUPERVISOR mode, processor provides access to additional set of instruction set.

I hope if you understand this concept you could answer yourself for your question. I have answered directly for many of your questions while explaining the concept itself.

  • 0
Reply Report