Hey everyone. Ok, so I know that from inside of any particular program, it see's through virtualized memory, a full range of available memory. It is given the ability then to place variables, data, user input etc, on the Stack, Heap, BSS, or Code segment of it's range. My question is what does the OS then do with this clump of requested memory? Does the OS itself have it's own form of data segementation like the stack and heap? What if the OS wants to run a service or something, where does it store it's variables, and user input?
Some supporting parts of the O/S run outside the kernel in processes, where they have a richer set of resources. The kernel wires down a certain amount of memory for code, i/o buffers and tables to support VM and i/o. The rest is shared via VM to all users, possibly even some functions of the kernel like disk cache. The methods for picking which page or RAM to assign to which page of what file or process address space vary (big bucks and deep thoughts). The hard rule is that dirty pages (written in RAM but not disk) must be written before they can be reassigned, and you do not want to erode the caller's working set, else the caller keeps calling for the same pages in rotation. They generally try to find the most idle pages but ensure all running processes have a reasonable 'working set' of pages in RAM. Sometimes high priority processes and pages get 'pin weights' that make them survive N more attempts at reassignment. Many pages are shared by many processes, so assigning ownership is difficult. Some O/S falsely mark pages unattached to see if another process will adopt them, but in a way that the page is not immediately freed up, so it can be readopted in place. Some processes can 'wire' some of their pages against the VM reassignment.
Mostly the kernel doesn't care what's in memory contents, as much as who they belong to. It just handles memory as undifferentiated pages, each having its own set of rwx permissions (handled in hardware). Mostly. Virtual memory allows it to set up triggers so special things can happen when a page is accessed, too.
Jeff Barryman wrote a whimsical explanation in 1972 which I've found somewhat helpful:
- Each player gets several million things.
- Things are kept in crates that hold 4096 things each. Things in the same crate are called crate-mates.
- Crates are stored either in the workshop or the warehouses. The workshop is almost always too small to hold all the crates.
- There is only one workshop but there may be several warehouses. Everybody shares them.
- Each thing has its own thing number.
- What you do with a thing is to zark it. Everybody takes turns zarking.
- You can only zark your things, not anybody else�s.
- Things can only be zarked when they are in the workshop.
- Only the Thing King knows whether a thing is in the workshop or in a warehouse.
- The longer a thing goes without being zarked, the grubbier it is said to become.
- The way you get things is to ask the Thing King. He only gives out things by the crateful. This is to keep the royal overhead down.
- The way you zark a thing is to give its thing number. If you give the number of a thing that happens to be in a workshop it gets zarked right away. If it is in a warehouse, the Thing King packs the crate containing your thing back into the workshop. If there is no room in the workshop, he first finds the grubbiest crate in the workshop, whether it be yours or somebody else�s, and packs it off with all its crate-mates to a warehouse. In its place he puts the crate containing your thing. Your thing then gets zarked and you never know that it wasn�t in the workshop all along.
- Each player�s stock of things have the same numbers as everybody else�s. The Thing King always knows who owns what thing and whose turn it is, so you can�t ever accidentally zark somebody else�s thing even if it has the same thing number as one of yours.
Notes
- Traditionally, the Thing King sits at a large, segmented table and is attended to by pages (the so-called �table pages�) whose job it is to help the king remember where all the things are and who they belong to.
- One consequence of Rule 13 is that everybody�s thing numbers will be similar from game to game, regardless of the number of players.
- The Thing King has a few things of his own, some of which move back and forth between workshop and warehouse just like anybody else�s, but some of which are just too heavy to move out of the workshop.
- With the given set of rules, oft-zarked things tend to get kept mostly in the workshop while little-zarked things stay mostly in a warehouse. This is efficient stock control.
This sounds like an awful lot of work, and is... But since it happens at the hardware level, mostly without the OS being involved, it's not so bad. The OS sets up big lists of pages and the processor uses them directly. This means things mostly happen by themselves -- smooth sailing until something needs to be paged in for whatever reason, or someone accesses memory they don't have access to. Then the processor stops that process and informs the OS somehow.
4 Likes
UNIX and most O/S do such a good job of making processes think they have an unlimited memory computer to themselves,they have to work pretty hard to communicate with each other. The effort is not much less than that to talk to another computer! However, two or more processes can share the same pages, not necessarily in exactly the same apparent location but in the same physical memory pages. For instance, almost every program shares libc, and with dynamic linking, one (executable or read only) copy serves all.
Oooh, if only I knew how to disable the MMU for a single byte read anywhere in contiguous memory on an x86 machine that has an OS up and running...
@Corona688, made me smile, nice and pinched... ;o)
@ Lost in Cyberia, although seriously deep reading at the core it might be worthwhile reading up about an MMU, Memory Management Unit as this controls all aspects memory allocation, paging, VM, 32 to 36 bit address pseudo-memory, etc...
No offense, but that's not really that useful anymore. The MMU has become an important part of I/O, disabling it would remove access to anything interesting.