>> Basically, yes. It'd be a 4GB virtual address space, but could be >> backed by a real 4GB RAM if there was appropriate hardware. Otherwise >> it could be backed by swap. > > If you're going to simulate virtual memory you'll need to tell the OS > when you've *finished* using a segment, so that it can save it to disk > again. Not necessarily - it would help the OS make better decisions about what to keep in memory and what needs to be written back to swap/whatever, but an assumption could be made that the 4 mapped segments are still in use until something else is mapped in, and any RW segment that is mapped is automatically dirty. I suppose the ABI design decision would be whether segments are assumed dirty-by-default or clean-by-default. Dirty-by-default: Easy to make functional - it's transparent to the app. Little added code bloat. But it's harder to make swapping perform optimally because the OS must always assume something has changed unless the app explicitly tells it "all done with DS, and it's the same as before". Bugs arising from incorrect use of that hint could be very frustrating, but debuggable with an OS setting to ignore the hinting. Clean-by-default: The compiler must atomically flag the segment as dirty with each write it does (this is where a real MMU kicks ass because the OS can track it itself). If writes aren't atomically done along with flagging dirty, the OS cannot mark it clean again if it is forced to swap out and back in due to memory pressure. In a cooperative multitasking environment, this could work very well because the OS won't swap it out during execution. It's just that cooperative multitasking sucks in other ways. To help cut down on extraneous write-backs in dirty-by-default, some hinting could be provided by using different calls for "map-for-read-only" and "map-for-read-write". Again, debugging bad usage of these would need an OS switch. But, it would help catch improper segment usage in some cases (mapping a RO segment for read-write). By the way, thanks for your input - it's valuable to have someone to bounce ideas off even if this never makes it into ELKS, because it will help me if I decide to implement some of this stuff in another project. -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
