> mixing up cache with real memory usage.

And how real is the use of memory for cache?

All this reminds me of a discussion I had with a mainframe admin in the mid-to-late 80's:

Me: Look at this numbers. We are using more than 90% of the processor time and about 100% of the memory. Is it normal?

Sysadmin: Good. We paid them in full. It's better if we use the whole computer, not just part of it.

In some cases, the sysadmin is right. Say you are concerned with performance, not energy-efficiency. If you have an I/O-bound workload that is only using 50% of your CPU cycles, wouldn't it be nice to automatically use the other 50% (otherwise wasted, mind you) to figure out some other things you might need in the future and prefetch them? On the memory side, what good is that 1GB or unused RAM doing you? If you need more for your application, the OS can drop its cache on the floor so quickly you'll hardly notice the latency.

Granted, this prefetching is not without downsides. DRAM banks have low-power states you can put them into if they're not being used, so if you can shove all of your used memory into a contiguous region of your physical address space and free up a DIMM's worth, you might be able to save power. This is unlikely, however, because the virtual-to-physical address mapping function is usually designed to spread the load very evenly across all available DRAM banks. One more likely source of power savings is from avoiding the CPU and disk activity of prefetching, especially if prefetch accuracy is low. Most people tend not to care about this though, and want the OS to make their app run faster by using otherwise-idle resources to do prefetching.

It was an 80's mainframe. I doubt power saving was one concern. We had folks typing forms in data-entry terminals 24x7 generating the tapes that were then fed to the bigger machine.

But you have an interesting idea. I wonder if there is any OS that changes memory distribution and allocation strategy according to desired power consumption on, say, portable computers.

The Linux kernel supports, IIRC, plug-and-play memory and processors and it could, conceivably (it it doesn't already) power up and down unused parts of the machine in order to reduce power consumption and heat dissipation. Even reads and writes to and from memory could be grouped in bursts if that could save power.

For instance, right now my running applications are within half of the memory, both cores are running slowly and the ethernet interface is disconnected. One memory module, one core and a network interface could be powered off without perceivable performance degradation. Also, as much data could be cached in the remaining memory so the disk could be powered down too or, and that would be interesting, spun at a lower speed.

Lots of interesting ideas in one lazy saturday afternoon. That's what I like in HN. :-)

In the mainframe world you're often paying by the processing unit consumed -- if you're not using the cycles you're not paying for them, and if you're using cycles you don't actually need to use you're just burning money.

In addition to local use, this is also every distributed computing project.