Hacker News new | past | comments | ask | show | jobs | submit login

> if all you need in the boot loader is to copy a gigabyte of 'ram' from one place to another and then jump to it

I suppose you don't even have to copy it before you jump to it. You could map the pages and then lazily copy when you get page faults.

> powering down servers that aren't being used with the ability to power them up in milliseconds

Still, if this is your goal, can't you get 90% of the way there by keeping some DRAM powered up while everything else is off? Refreshing DRAM requires some power, but not that much from what I understand (as a software guy).




On keeping DRAM alive, at NetApp where the company built custom motherboards specifically for filers, this continued to be an issue for the memory controllers in the processor chips. Neither AMD nor Intel had any support for staying clear of the DRAM configuration on power up of their server chips. There was an interesting config in one of their laptop chips but no ECC on that chip so it was a non starter. At Google the motherboards were less customized and even less likely to incur a Google specific cost of something like holding up memory. The benefit of this coming from Intel is that they do the work to qualify it and everyone else gets to reap the benefits.

The memory bus on these processors is 3 - 30 GBs so copying a full gig would be a 3 - 30mS sort of deal.A pretty short start time. And yes, you tell the BIOS to skip POST (its a common start up option in even off the shelf BIOS packages these days) in order to get a faster boot time.


Netapp can also get rid of their NVRAM architecture. More importantly any journaling file system can have in memory logging now and replication means just transfer the fs transaction logs.


> The memory bus on these processors is 3 - 30 GBs so copying a full gig would be a 3 - 30mS sort of deal

This should say 30 - 300ms I think


> I suppose you don't even have to copy it before you jump to it. You could map the pages and then lazily copy when you get page faults.

You could also just map it and not even fault on access. For data that's mostly read and seldom written, and not too much of a hot spot, there would be no reason to move it to DRAM. Depending on the read latency of these DIMMs, that might include a lot of executable code.


> keeping some DRAM powered up while everything else is off?

STR suspend to ram, available in off the shelf computers since ~1995


Novice in these contexts but I think it would be less of a saving as DRAM must be refreshed, at a pretty high clockrate too, typically.


DRAM has a self-refresh mode powered by an internal clock that you use for low-power standby, so this is not a problem. The DRAM just need to be powered.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: