Re: Some words of encouragement

Brad Normand
2012-02-25T23:05:20Z

>> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html