OSDev.org

willedwards wrote:Back in the day it wasn't uncommon to run the OS straight from ROM

There's a huge difference between NVRAM and ROM. By definition, ROM is always in a known state. NVRAM is more like a Hard Drive, where the state is only known immediately after being formatted. After that, it tends to slowly deteriorate over time, until it eventually fails due to unexpected conflicts, or physical failure.

For a few decades, most computers actually did use NVRAM (in the form of magnetic-core memory). They still used disks for long-term storage and still used core memory pretty much the same way as volatile RAM is used now. So I'm not really expecting much difference.

Hi,

I've been thinking about this (on and off) for about 6 months now. What I've come up with is...

There's about 4 different use cases for memory:

• sensitive data that shouldn't be exposed
• normal temporary data
• data that could be persisted
• data that must be persisted

For sensitive data that shouldn't be exposed, the OS can't really do anything, and has to leave it up to processes to take care of (e.g.) wiping passwords, etc from memory as soon as they can. For this it doesn't make much difference if the memory is volatile or not - software should wipe the data even if the RAM is volatile because even volatile RAM retains information for long enough for information that was in RAM to be "stolen" after the system is turned off.

For normal temporary data, the data is temporary and doesn't need non-volatile RAM in the first place.

For data that must be persisted, you can't really rely on non-volatile RAM for storage because anything could happen between an OS shutting down and the same OS starting up again (especially when dual boot is involved). This means you need hardware dedicated for permanent storage (e.g. SSD, hard disk) and non-volatile RAM doesn't make any difference.

This only leaves "data that could be persisted". For any sane OS you've got some sort of file system cache somewhere (e.g. built into VFS). If this file system cache data was encrypted (in case it's also sensitive data), and if there was a way to find it again after boot, and if (e.g.) checksums are included to ensure the data hasn't been corrupted; then boot times could be improved (safely) by re-using any "still OK" data from last time to pre-populate the file system cache during boot.

Basically; "file system cache tweaks" is the only way to make use of non-volatile RAM that I've been able to think of (and it saddens me a little that I haven't been able to think of anything more interesting or more revolutionary ).


Cheers,

Brendan

Brendan wrote:Hi,

I've been thinking about this (on and off) for about 6 months now. What I've come up with is...

There's about 4 different use cases for memory:

• sensitive data that shouldn't be exposed
• normal temporary data
• data that could be persisted
• data that must be persisted

For sensitive data that shouldn't be exposed, the OS can't really do anything, and has to leave it up to processes to take care of (e.g.) wiping passwords, etc from memory as soon as they can. For this it doesn't make much difference if the memory is volatile or not - software should wipe the data even if the RAM is volatile because even volatile RAM retains information for long enough for information that was in RAM to be "stolen" after the system is turned off.

Not to mention that if the process exits without wiping data the OS could end up assigning a page with sensitive data on it to another process, which could in theory be a malicious process repeatedly mmaping pages, scanning them for data of interest, and munmapping them. This is probably a strategy that is fairly unlikely to succeed in general situations, but could probably capture sensitive data in special situations.

This only leaves "data that could be persisted". For any sane OS you've got some sort of file system cache somewhere (e.g. built into VFS). If this file system cache data was encrypted (in case it's also sensitive data), and if there was a way to find it again after boot, and if (e.g.) checksums are included to ensure the data hasn't been corrupted; then boot times could be improved (safely) by re-using any "still OK" data from last time to pre-populate the file system cache during boot.

Recovery from unexpected power loss is another situation that falls under "data that could be persisted".

For data that must be persisted, you could still replace SSD/HDD with NVRAM as long as you had it organized the right way- put a partition table on it, essentially (though it could be more flexible if you wanted). Dual boot OSes would still have to agree to follow that structure the same as they do on more traditional permanent storage.

That's assuming that the only NVRAM in the system is accessed as the processor's physical address space, though- the other option is to replace SSD/HDD with it (as well as normal RAM) and design your OS around the much-faster transfer speeds that would provide. Swapping might be less of an issue, for example.

I discussed this with a former co-worker over lunch today, and the main advantage he came up with would be for embedded devices, like routers. If you unplug your router, or if the power flickers today, your router reboots to a known state, and then starts building its internal lookup tables over time. Using nvram in these types of devices would allow you to recover from a power outage in just a second or two (or maybe less), by not needing to restart the embedded OS, and not having to rebuild these tables.

You would just have to be careful when updating this nvram, to make sure a power outage didn't corrupt the state of these tables (journaled file system?), and you would still need some reliable way to force a clean reboot, which would restart the system and rebuild the tables, in case of a software glitch that locks up the machine, but I could see this being a case where nvram would be beneficial, if the cost were not an issue.

But for laptops with built in batteries, I don't see much of an advantage. Maybe for desktop PCs with no battery backup?? Maybe...

Brendan wrote:Basically; "file system cache tweaks" is the only way to make use of non-volatile RAM that I've been able to think of (and it saddens me a little that I haven't been able to think of anything more interesting or more revolutionary

The "tweaks" can be thought of as a wide range of possibilities. Is the speeding up of the system hibernation included in the "tweaks"? Is the case of quick reboot after power outage with processor's state (and a bit more system information) saved to the NVRAM included? Is the non-volatile data access (read and write) included?

Basically, all the data that a developer thinks should be (at least temporarily) non-volatile, can be accessed quicker than in case of HDD (if NVRAM is quicker than HDD). But the problem is to separate the volatile and non-volatile cases clearly because of a lot of pre- and post-processing involved in many software operations. Next problem is to compare the pros and cons of NVRAM based solution vs volatile RAM based solution considering all required information available (speed, power, cost and so on). I think that many cases will emerge when developers will work on a particular problem with two options in mind - the NVRAM and volatile RAM. But all the cases mostly won't be kind of a revolution.

Of course one must remember that, when separating "volatile" and "non-volatile" data as the prevous poster suggested, any system "volatile" data prevents the instant-recovery-without-data-loss-from-power-failure benefit (which to me is the most significant benefit). This is because if the system were to resume from a previous state, but with all "volatile" data missing, it would be unstable - applications would still expect that "volatile" data to exist, but it does not. As the "volatile" data is not "you can get rid of this whenever you want, without warning me" (as indeed any system which stores data in such manner is practically unusable and would be nearly impossible to program) but rather "if the power fails or the system crashes, this data is not essential". Thus in any system containing distinct "volatile" and "non-volatile" data, it would be strongly unadvisable and most likely impossible to instantly resume it in the case of a power failure, but instead one would be able to only dump the remaining "non-volatile" data to disk for later recovery once the system has been rebooted or the data has been transferred to another system.

A lot of misunderstanding going on here.

The ability to force a clean reset has almost nothing to do with NVRAM- it just means you put all your non-persistent state (approximately everything we store in volatile RAM today) in one particular section of NVRAM that you can easily discard by deallocating it and jumping to the initialization code, which will then act as if that state had been lost (it's really still there, just treated as leftover garbage now).

Rusky wrote:A lot of misunderstanding going on here.

The ability to force a clean reset has almost nothing to do with NVRAM- it just means you put all your non-persistent state (approximately everything we store in volatile RAM today) in one particular section of NVRAM that you can easily discard by deallocating it and jumping to the initialization code, which will then act as if that state had been lost (it's really still there, just treated as leftover garbage now).

This is why NVRAM makes little sense on a modern PC... If the "non-persistent" partition can be discarded, the OS has to be able to work without it, if it's not there. Therefore, it must keep all important information on the "persistent" partition. That's essentially what we have now, with Sleep mode and Hibernate mode. So it's probably not worth the trouble of redesigning the PC around NVRAM.

If the "non-persistent" partition can't be discarded, then the OS can assume it will always be there, and take advantage of it. But then the problem becomes stability over long periods of time. I think this is unrealistic, based on the fact that all software has some level of unexpected behavior, so I think the first approach is still the only real option, but I don't think it will get any market traction, for the reasons listed above.

So, probably not worth worrying about right now.

Basically; "file system cache tweaks" is the only way to make use of non-volatile RAM that I've been able to think of (and it saddens me a little that I haven't been able to think of anything more interesting or more revolutionary ).

I wouldn't feel too bad. Microsoft tried to use USB thumb drives as a "tweak", when they added "Speed Boost", but I'll be d*** if I can tell a difference with it turned on. Fail.

SpyderTL wrote:If the "non-persistent" partition can be discarded, the OS has to be able to work without it, if it's not there.

Nonsense. It can't just be discarded any time for any reason- it's discardable by the OS and only as part of a system reset, just like normal RAM. Otherwise it's just as non-volatile as the rest (i.e. in case of power failure and as a replacement for sleep/hibernation)- it would be considered memory corruption for it to just disappear out from under the system.

Rusky wrote:

SpyderTL wrote:If the "non-persistent" partition can be discarded, the OS has to be able to work without it, if it's not there.

Nonsense. It can't just be discarded any time for any reason- it's discardable by the OS and only as part of a system reset, just like normal RAM. Otherwise it's just as non-volatile as the rest (i.e. in case of power failure and as a replacement for sleep/hibernation)- it would be considered memory corruption for it to just disappear out from under the system.

If the OS is malfunctioning, having the OS clear the nvram may not be an option. Clearing RAM is a simple matter of rebooting. Clearing NVRAM requires a functioning system of some type, probably the BIOS or something in ROM on the machine. But that would require that the ROM understand your "partition" strategy above, so that it knows what to clear and what to leave alone.

I'm still thinking RAM is a better choice, all things considered. I'm making a lot of assumptions, though.

The only functionality the OS needs is to be able to jump to a known-good reset vector, and from there it can understand the partitioning format and just ignore the leftover contents of the volatile section. So as long as the reason you're resetting is not equivalent to file system corruption, there's no problem.

"Equivalent to file system corruption"... That's actually a scary thought in the context of a monolithic kernel: Any rogue pointer that would today cause memory corruption (which would be "fixed" by a reboot) could end up causing file system corruption when your whole "disk" is mapped as RAM.

onlyonemac wrote:Of course one must remember that, when separating "volatile" and "non-volatile" data as the prevous poster suggested, any system "volatile" data prevents the instant-recovery-without-data-loss-from-power-failure benefit (which to me is the most significant benefit).

Also one should remember the use case for NVRAM. It just replaces the volatile RAM, so, the volatile data is still alive even after power outage. But the timing issues can prevent the NVRAM from replacing entire system RAM. In the last case it is required to carefully think about what is volatile and what is not, what can be moved into the RAM and how we can recover after the power is switched off.

In case when NVRAM completely replaces RAM it is still possible to save the tiny amount of volatile state and to restart the system instantly after the power switch. Even in case of partial replacement there are some possibilities (but more complex) that allow to write a system with very small (re)boot time. But the main point here is the importance of such a small boot time. I see it as such - almost all users will agree to keep the existing solutions (sleep, hibernate) if they are asked to pay just for the boot time reduction.