Hi,
quanganht wrote:
Fragmentation can be solved by using some kind of block(slab?). So, up on application's request, system allocator will give it a chunk of memory, say 1MB, or even 1GB. Then application is free to do anything with it.
That works perfectly fine for a normal OS, because a normal OS allocates space (and not RAM). For "contiguously mapped RAM" you can't give every process a large slab because you end up wasting heaps of RAM. For example, the computer I'm using now isn't doing too much, but there's about 50 processes running. If you give each process 1 GiB then you'll need to use significant amounts of swap space (but you can't implement swap space for "contiguously mapped RAM" either).
Probably the easiest way around the problem is to have (the equivalent of) a global heap; but then the RAM allocated by a single process will be scattered all over the place (not so good for cache/TLB locality). Of course that's assuming you can prevent heap corruption.
A better idea is to not use "contiguously mapped RAM" to begin with - that solves all the problems.
quanganht wrote:
Another optimization that only SAS can have is shared memory. IPC, RPC, shared data is *very* efficient in SAS because data is placed in one place only, then owner can pass it's pointer to anyone
Boring old fashioned OSs (e.g. Unix clones) have been using shared memory (without SAS) for several decades.
The optimisation that you're thinking of means that you can pass a pointer to something in shared memory rather than passing an offset from the start of shared memory. For e.g. (for a more conventional OS) the first process can do "offset = pointer - address_of_shared_memory" and send the offset, and the second process (the receiver) can do "pointer = offset +address_of_shared_memory"; and instead of this a SAS OS can just send the pointer. It saves you one subtraction and one addition, or about 2 cycles on a modern CPU (until the receiver has to check if the pointer it received is sane, where you need to do 2 comparisons instead of one).
The main advantage (the only significant advantage) that SAS has is eliminating the cost of switching virtual address spaces (e.g. TLB misses). Unfortunately this advantage is often over-estimated.
The TLBs in a modern CPU aren't large enough to cover the entire virtual address space (even with "large pages" they aren't enough to cover 4 GiB of the virtual address space). The TLBs only cover the most recently used areas of the address space. This means a SAS OS runs one process (and the TLB fills with entries for that process), then the SAS OS switches to a different process (and almost all of the TLB entries for the old process and aren't used, and get replaced by TLB entries for the new process, and you get the same number of TLB misses). Of course that's a "worst case".
If the OS is constantly switching between "n" processes, and if those processes use less data than the TLBs cover, then a SAS OS does avoid lots of TLB misses. That's the "best case".
quanganht wrote:
quanganht wrote:
any pointer made by any process will be globally correct
Similar to this
http://forum.osdev.org/viewtopic.php?f=15&t=21393#p170267Plus, SYSCALL/SYSRET requires flat, paged memory model. That is doubled speed over call gate/SW interrupt. Well 20 cycles times some million calls is something really different
SYSCALL/SYSRET doesn't a require flat paged memory model - for a 32-bit OS it'll work without paging and you can still use a limited amount of segmentation (e.g. for data segments). Long mode requires flat paged memory model (therefore a flat paged memory model is required for SYSCALL/SYSRET in long mode).
Of course "requires a paged flat memory model" only means you can't rely on segmentation and have to use paging (but it doesn't matter *how* you use paging - it could be a monolithic OS with a virtual address space for each process, or a SAS OS, or any other alternative).
quanganht wrote:
And about this
Brendan wrote:
and no easy way to implement protection/isolation
I doubt it. IMO we only have to watch out page tables, and mark pages with permissions corresponding to applications.
"Mark pages with permissions corresponding to applications."???
If you've got a single address space for all processes, then you could mark all "user-level pages" that the currently running process shouldn't be able to access as "not present" or "supervisor" (e.g. during the task switch); but if you do that you'll need to flush/invalidate all of the TLB entries that you modify (and if you need to flush all of the TLB entries then it's easier and faster to use multiple address spaces and just change CR3 instead).
For a SAS OS, the only sane options are:
- are no security/protection at all - e.g. a games machine or something where no data matters much, or an embedded system where you can guarantee that all the code that can be run is "safe" (where all the code is extremely well tested and stored in ROM or something).
- Software isolation. This could mean processes run inside a virtual machine - e.g. byte-code that is interpreted, or compiled while it runs (dynamic translation/JIT), or compiled when it's installed.
For these options, software isolation is probably the most interesting, but it's a massive amount of work for a small (potential) performance improvement (unless you can recycle someone else's work).
Cheers,
Brendan