While going through the slides of a lecture on memory management, I came across this:
Relocation register value is static during program execution. Hence all of the OS must be present (it might be used). Otherwise, we have to relocate user code/data “on the fly”! In other words, we cannot have transient OS code
I couldn't understand what the above lines meant. I would appreciate if anyone could explain this.
The relocation-register scheme provides an effective way to allow the
operating system’s size to change dynamically. This flexibility is desirable in
many situations. For example, the operating system contains code and buffer
space for device drivers.
If a device driver (or other operating-system service) is not commonly used, we do not want to keep the code and data inmemory, as
we might be able to use that space for other purposes. Such code is sometimes
called transient operating-system code; it comes and goes as needed. Thus,
using this code changes the size of the operating system during program
execution.
All the logical memory references in user code are mapped to physical address space using Relocation Register value.(Phy.add = Rel.reg_val + log.add).
The value of Relocation-Register is set by OS. So it will be unaffected by user processes.
A transient code in Operating System means that it is active for just small time (useless for long time like code to check if the processor is deadlocked). So the Relocation-Register Scheme tries to allocate the memory occupied by this transient code to some other process in job Queue of Main Memory.Shrinking or expanding OS process boundary with nearby processes (because of single partition allocation).
By knowing above points, if transient code is present in OS, due to changes in boundaries of processes with OS process, we should be able to relocate user code/data frequently.
Related
Currently I'm reading books on Operating Systems Design. However, I'm not quite clear how Operating Systems do behave, when the number of free pages in memory is smaller than the working set of a process.
From the OS side, maybe it will prevent the process from being loaded into memory?
And from the developer side, what can they do to improve the situation?
I suspect your confusion here is related to the meaning of the term "working set." That term has a different meaning in theoretical computer science and in operating system implementation.
In the former, a working set is the amount of memory a process requires at a given time.
In the later, a working set is the amount of physical memory a process has at a given time. (some systems may use a different definition).
A process gets what the operating system gives it. The operating system can only give what is has available. If a process needs more physical memory, the OS either gives what it has free or to takes from another process.
When a process starts up, its working set will be zero (or close to zero). A process only gets physical memory when it causes a page fault. If you monitor a program, you typically see a lot of page faults when the program starts then the number starts to level off (Unless the program uses a lot of virtual memory relative to the physical memory of the system).
Assume that we have the CPU that has MMU, which works as follows:
for memory management is used only paging
every process has own page table
virtual address of every process is split into user space and kernel
space (like many CPUs with paging does)
kernel space (concretely his virtual addresses) is shared between all
processes (for example higher addresses)
Now imagine that, we are running several processes (of course in non-privileged mode). When we want to allocate additional memory for any process, it just apply following scenario in my opinion. We execute system call(s) and OS serves that (in privileged mode) by updating process page table or report some error code.
My question: But now, when we want to allocate some memory for kernel, we must update all tables of all processes in their kernel part addresses? As far as I know there isn't any kernel page table, which can theoretically solve that problem (but brings others), in CPUs that works similarly. So how to solve that situation, if is possible to occur?
Sorry for my English.
Finally, I found solution. I think, this link say it all:
ARM Solution
Very important to understand that is Table 6.13. Translation table size. In a short, the virtual space of every process is divided into kernel space and user space, of course. However, both spaces have own table. When process switch, kernel table pointer is constant, but user table pointer is changed. I hope, you understand that.
Sorry for my English.
When a fork is called, the stack and heap are both copied from the parent process to the child process. Before using the fork system call, I malloc() some memory; let's say its address was A. After using the fork system call, I print the address of this memory in both parent and child processes. I see both are printing the same address: A. The child and parent processes are capable of writing any value to this address independently, and modification by one process is not reflected in the other process. To my knowledge, addresses are globally unique within a machine.
My question is: Why is it that the same address location A stores different values at the same time, even though the heap is copied?
There is a difference between the "real" memory address, and the memory address you usually work with, i.e. the "virtual" memory address. Virtual memory is basically just an abstraction from the Operating System in order to manage different pages, which allows the OS to switch pages from RAM into HDD (page file) and vice versa.
This allows the OS to continue operating even when RAM capacity has been reached, and to put the relevant page file into a random location inside RAM without changing your program's logic (otherwise, a pointer pointing to 0x1234 would suddenly point to 0x4321 after a page switch has occured).
What happens if you fork your process is basically just a copy of the page file, which - I assume - allows for smarter algorithms to take place, such as copying only if one process actually modifies the page file.
One important aspect to mention is that forking should not change any memory addresses, since (e.g. in C) there can be quite a bit of pointer logic in your application, relying on the consistency of the memory you allocated. If the addresses were to suddenly change after forking, it would break most, if not all, of this pointer logic.
You can read more on this here: http://en.wikipedia.org/wiki/Virtual_memory or, if you're truly interested, I recommend reading "Operating Systems - Internals and Design Principles" by William Stallings, which should cover most things including why and how virtual memory is used. There is also an excellent answer to this in this StackOverflow thread. Lastly, you might want to also read answers from this, this and this question.
Reading OS from multiple resources has left be confused about supervisor mode. For example, on Wikipedia:
In kernel mode, the CPU may perform any operation allowed by its architecture ..................
In the other CPU modes, certain restrictions on CPU operations are enforced by the hardware. Typically, certain instructions are not permitted (especially those—including I/O operations—that could alter the global state of the machine), some memory areas cannot be accessed
Does it mean that instructions such as LOAD and STORE are prohibited? or does it mean something else?
I am asking this because on a pure RISC processor, the only instructions that should access IO/memory are LOAD and STORE. A simple program that evaluates some arithmetic expression will thus need supervisor mode to read its operands.
I apologize if it's vague. If possible, can anyone explain it with an example?
I see this question was asked few months back and this should have been answered long back.
I will try to set few things straight before talking about I/O part of your question.
CPU running in "kernel mode" means that OS has permitted CPU to be able to execute few extra instructions. This is done by setting some flag at an appropriate moment. One can think of it as if a digital switch enables or disables specific operations embedded inside a processor.
In RISC machines, LOAD and STORE are generally register related operations. In fact from processor's perspective, traffic to and from main-memory is not really considered an I/O operation. Data transfer between main memory and processor happens very much automatically, by virtue of a pre-programmed page table (unless the required data is NOT found in main memory as well in which case it generally has to do disk I/O). Obviously OS programs this page table well in advance and does its book keeping operations in it.
An I/O operation generally relates to those with other external devices which are reachable through interrupt controller. Whenever an I/O operation completes, the corresponding device raises an interrupt towards processor and this causes OS to immediately change the processor's privilege level appropriately. Processor in turn works out the request raised by interrupt. This interrupt is a program written by OS developers, which may contain certain privileged instructions. This raised privileged level is some times referred as "kernel mode".
I wanted to know why code segment is common for different instances of same program.
For example: consider program P1.exe running, if another copy of P1.exe is running, code segment will be common for both running instances. Why is it so?
If the code segment in question is loaded from a DLL, it might be the operating system being clever and re-using the already loaded library. This is one of the core points of using dynamically loaded library code, it allows the code to be shared across multiple processes.
Not sure if Windows is clever enough to do this with the code sections of regular EXE files, but it would make sense if possible.
It could also be virtual memory fooling you; two processes can look like they have the same thing on the same address, but that address is virtual, so they really are just showing mappings of physical memory.
Code is typically read-only, so it would be wasteful to make multiple copies of it.
Also, Windows (at least, I can't speak for other OS's at this level) uses the paging infrastructure to page code in and out direct from the executable file, as if it were a paging file. Since you are dealing with the same executable, it is paging from the same location to the same location.
Self-modifying code is effectively no longer supported by modern operating systems. Generating new code is possible (by setting the correct flags when allocating memory) but this is separate from the original code segment.
The code segment is (supposed to be) static (does not change) so there is no reason not to use it for several instances.
Just to start at a basic level, Segmentation is just a way to implement memory isolation and partitioning. Paging is another way to achieve this. For the most part, anything you can achieve via segmentation, you can be achieve via paging. As such, most modern operating systems on the x86 forego using segmentation at all, instead relying completely on paging facilities.
Because of this, all processes will usually be running under the trivial segment of (Base = 0, Limit = 4GB, Privilege level = 3), which means the code/data segment registers play no real part in determining the physical address, and are just used to set the privilege level of the process. All processes will usually be run at the same privilege, so they should all have the same value in the segment register.
Edit
Maybe I misinterpreted the question. I thought the question author was asking why both processes have the same value in the code segment register.