Single Address Space OS and processes

[narke]

Hello,

I am coding an Single Address Space OS. Now I want to implement threads and process management, so I have a question:
Does processes really matter in SAS OS? To switch from one process to another I must change the page directory (1 page directory maps 4GB on IA32) so would this be an SAS OS by design?
How to implement processes on a such a system without changing the address space?

Thank you guys!

[Solar]

I am not sure what you're saying, here. Why do you have to change the page directory at all? Where's the problem with creating processes? (As in, things the scheduler can work with, not address spaces, of course.)

[narke]

I said that because in a Single Address Space OS you must have access to the whole virtual memory (4GB on IA32) but processes must have different address spaces (they are separated), so how these two concept can coexist?

[Solar]

Erm... no, they don't?

Single Address Space (n.), a concept where a computer system provides only a single address space (hence the name) for all processes.

Memory Protection (n.), a concept where each process recieves its own address space, so that one process cannot accidentially or intentionally overwrite another process' code or data.

Unless I am severly mistaken and there is some bastardized hybrid.

[Combuster]

Unless I am severly mistaken and there is some bastardized hybrid.

Software isolated processes?

[Brendan]

Hi,

Unless I am severly mistaken and there is some bastardized hybrid.

Software isolated processes?

For 32-bit 80x86 (implied by the original poster's "1 page directory maps 4GB on IA32), using segmentation to isolate processes could also work.

The problem with single address space is that it's either very crappy compared to other OSs, or very complex compared to other OSs; and "very complex compared to other OSs" may not be a practical option for a hobby OS (as even simple OSs can consume the best part of a decade to become usable).


Cheers,

Brendan

[Colonel Kernel]

In addition to SIPs and segmentation, there is another technique where you assign each process a contiguous chunk of the single virtual address space, and protect processes from each other by changing page protections on each process switch. I think Windows CE does this. It's a pain because it's slow and imposes a lot of constraints on processes (they must be relocatable, must use very little memory, etc.).

The problem with single address space is that it's either very crappy compared to other OSs, or very complex compared to other OSs

Agreed.

[Solar]

Define "very crappy". You don't get memory protection, which is somewhat implied in the concept. And you might get some memory fragmentation issues without paging. But other than that?

[Combuster]

As if a broken in design memory management and a total lack of security isn't "very crappy" enough... That's obviously is a order of magnitude worse than windows, which already is crap by your definition

[Solar]

Most embedded OS'es don't give a damn about memory protection. AmigaOS didn't, either, and was an example of fine engineering in many other respects (as well as solving the SAS issue quite elegantly).

OP wants to do a SAS OS. Instead of telling him "that's crap", why not try to learn about his motives?

[narke]

I want to have an SAS OS in order to have orthogonal persistence. The kernel is working in ring 0 and the whole OS would run in ring0 in order to speed up the OS.
There is an interesting page here http://c2.com/cgi/wiki?SingleAddressSpa ... tingSystem where it's said that OS-9 uses also an SAS architecture so I think that it would be feasible to get an decent OS.

I will investigate the Software based Isolation (used by Singularity).

Solar: can you tell me please how AmigaOS managed to solve SAS issues? If I remember correctly you once posted that you used AmigaOS in old days.

Thank you guys, and don't hesitate to share you ideas.

[Brendan]

Hi,

Define "very crappy". You don't get memory protection, which is somewhat implied in the concept. And you might get some memory fragmentation issues without paging. But other than that?

It depends which way you want the OS to suffer for no reason...

The only sane reason to use a single address space is to avoid the overhead of address space switching (TLB misses). For a 32-bit OS that uses one address space, all processes combined can't really use more than 4 GiB of RAM. Worse, any memory mapped PCI devices would cut into this - if your video card has 2 GiB of VRAM then all processes can only share the last 2 GiB. Then there's things like memory mapped files, where a big chunk of the virtual address space might be consumed (or reserved) for a large file. Now assume the end user is running 128 processes on a computer with 16 GiB of RAM, and try to explain to them why processes are limited to an average of 16 MiB each, and why there's 14 GiB of RAM that's being wasted...

You can avoid this particular problem by allowing parts of the address space to be modified during task switches, but then you've lost the only sane reason to use a single address space to start with (you're back to having TLB misses). All you've really done is increase complexity for no real gain. Of course there's compromises - for example, you could try to keep processes that are most likely to be used in the address space in an attempt to minimize the chance of TLB misses (with an even larger increase in complexity).

For a 64-bit OS this problem goes away because the single address space can be huge; but in this case you can't use segmentation, and without any protection between processes your OS becomes a security nightmare. To avoid this you could do software isolation, but writing your own compiler (and guaranteeing that the code it produces is both correct *and* secure) will bring you back to "very complex" in a hurry.

Of course the idea that using a single address space will avoid TLB misses is fairly dodgy to begin with - it's not like the TLB has infinite size. Least recently used TLB entries will be evicted when the CPU needs space for new TLB entries; so while you're running one process, the TLB entries from other processes will probably be evicted anyway, and when you switching between several processes (e.g. A -> B -> C -> A -> B -> C) you'll be lucky if any TLB entries are still be present after a task switch (despite using the same address space). Maybe if the processes don't do much then the TLB entries for all processes will remain, but if the processes don't do much then who cares about overhead anyway?

If anyone is in doubt, here's the details for Intel's Core I7 CPU (which probably has larger TLBs than most (all?) 80x86 CPUs):

• 64 entry L1 TLB for 4 KiB pages
• 32 entry L1 TLB for 2/4 MiB pages
• 512 entry L2 TLB for 4 KiB pages

Assuming you're only using 4 KiB pages, that means that the TLB for each core is large enough to cover 2304 KiB of the virtual address space, but each core is shared by 2 logical CPUs (hyper-threading), so on average a process only needs to touch a little over 1 MiB of data before the TLB entries for all other processes (and the kernel) are evicted.

Using 2 Mib pages (in addition to 4 KiB pages) would help to actually get some benefit from the attempt to avoid TLB misses, but that's going to turn your physical memory management (and your fragmentation issues) into a slow/complex mess. Using 2 MiB pages only (without 4 KiB pages) is much easier, but then you'd waste an average of 3 MiB (of both RAM and address space) per process (assuming that each process has an average of 3 areas with different page protection flags - e.g. an "execute allowed code" area, a "read only data" area, and a "read/write data" area, with an average of 1 MiB wasted per area per process).

Basically there's lots of different ways of doing a single address space OS, but they all lead to a compromise between "crappy" and "complex".


Cheers,

Brendan

[johnsa]

I'm all for complex here...

The approach I've taken with my OS is similar in that it is 64bit only, all ring0 and shares a single address space. I use 2Mib pages configured once by the kernel for the available physical memory, all cores share the same paging structure.
In terms of memory management I've not had an issue with this design as once this is in place I basically ignore "pages" and don't do allocation via a stack of free/used pages. I do allocation and free's at byte granularity and coalesce areas when they free (it might incur a little bit of overheard but it's working like a dream for me).

The other issues around SAS OS are (especially in 64bit with no segmentation) ensuring that your executables/modules/image/libraries etc can be dynamically relocated. I wrote a COFF64 linker based on the work from another thread on this forum for 32bit COFF. I'm busy adding built in compression to the binary/image to keep the size of the relocations down, although sofar it hasn't been too bad as about 60-70% of the code is PIC anyway.

In terms of protection... I don't really care about this.. if I were building an OS for every Joe Soap to use, then yes it would be important but for my project the OS works as more of a platform for me to develop applications/systems on top of. Ideally even though it would multi-task it's purpose is to run one single dedicate system.. (IE: a DB server, web server, processing node, rendering engine). As far as I'm concerned ring/memory protection etc is like having a bicycle with training wheels on it... yes it'll stop you from falling over if you don't know what you're doing, but ideally you should be spending your time learning to not fall in the first place.. (IE: if the OS breaks because an app did something stupid... then fix the app), the OS isn't going to be an excuse for shoddy applications with bugs.

[samueldotj]

Unless hardware has some kind of support for single address space, implementation of single address space kernel might look crappy and IMHO it is difficult to implement SAS on x86-32/x86-64.

However writing SAS kernel for any SAS supported architecture wont be much complicated relative to writing a MAS kernel for the same architecture. Eg: IA-64 and PA architectures has support for single address space. HP-UX is SAS operating system which is relies on hardware protection and uses no software controlled mechanism for protection.