Article: Intel’s Plans for 3DXP DIMMs Emerge
By: Ricardo B (ricardo.b.delete@this.xxxxx.xx), July 24, 2018 9:24 am
Room: Moderated Discussions
Adrian (a.delete@this.acm.org) on July 24, 2018 7:35 am wrote:
> Except that you avoid the need for a custom program for saving and restoring the memory,
> this is a technical solution which is inferior to just using standard DIMMs and an UPS.
>
> Writing the custom program would be a one-time expense, immediately recovered at the current
> DRAM prices. Maybe such a program already exists, I have not bothered to search.
>
> Even if none can be found, it cannot require more than a few days of work to write it and to integrate it
> with a bootloader. This could be done in a way transparent for the OS, e.g. you could write a kernel module,
> which could be entered e.g. with a ioctl after the UPS signaled the power failure. The kernel module could
> save a memory & registers image on a SSD, then shut down the computer. The memory and the registers could
> be restored from the image after power-on by a custom boot loader, which will jump then back to the kernel
> module (some way to store the jump address at a fixed address would be required), which will return to userland.
> Thus, except for a jump in time, the OS and all the other programs would not feel that the computer was shut
> down and the memory content would be as persistent as with NVDIMMs, but at a much lower cost.
>
You know you've just described hibernation, which is supported by every major computer OS nowadays, right?
However, losing mains power supply is only one of the concerns.
You can have have a power supply or a power regulator suddenly die, among other problems.
These concerns are not some theoretical or exotic exercise.
Common operative systems and other applications "waste" considerable performance writing data to persistent storage in a controlled sequence (eg, journalism) to ensure that in case of an expected shutdown you boot into a consistent state.
A traditional way to reduce the performance impact has battery or Flash backed write cache units for RAID controllers.
Battery or Flash backed DRAM DIMMs are yet another way to address this performance impact.
> Except that you avoid the need for a custom program for saving and restoring the memory,
> this is a technical solution which is inferior to just using standard DIMMs and an UPS.
>
> Writing the custom program would be a one-time expense, immediately recovered at the current
> DRAM prices. Maybe such a program already exists, I have not bothered to search.
>
> Even if none can be found, it cannot require more than a few days of work to write it and to integrate it
> with a bootloader. This could be done in a way transparent for the OS, e.g. you could write a kernel module,
> which could be entered e.g. with a ioctl after the UPS signaled the power failure. The kernel module could
> save a memory & registers image on a SSD, then shut down the computer. The memory and the registers could
> be restored from the image after power-on by a custom boot loader, which will jump then back to the kernel
> module (some way to store the jump address at a fixed address would be required), which will return to userland.
> Thus, except for a jump in time, the OS and all the other programs would not feel that the computer was shut
> down and the memory content would be as persistent as with NVDIMMs, but at a much lower cost.
>
You know you've just described hibernation, which is supported by every major computer OS nowadays, right?
However, losing mains power supply is only one of the concerns.
You can have have a power supply or a power regulator suddenly die, among other problems.
These concerns are not some theoretical or exotic exercise.
Common operative systems and other applications "waste" considerable performance writing data to persistent storage in a controlled sequence (eg, journalism) to ensure that in case of an expected shutdown you boot into a consistent state.
A traditional way to reduce the performance impact has battery or Flash backed write cache units for RAID controllers.
Battery or Flash backed DRAM DIMMs are yet another way to address this performance impact.
Topic | Posted By | Date |
---|---|---|
New article on Intel's 3DXP | David Kanter | 2018/07/23 10:02 AM |
New article on Intel's 3DXP | Groo | 2018/07/23 01:53 PM |
New article on Intel's 3DXP | Michael S | 2018/07/23 02:47 PM |
New article on Intel's 3DXP | Teemo | 2018/07/23 05:38 PM |
New article on Intel's 3DXP | Wes Felterw | 2018/07/23 09:41 PM |
Flash DIMMs = bad idea | David Kanter | 2018/07/24 04:31 AM |
Flash DIMMs = bad idea | Emil Briggs | 2018/07/24 06:30 AM |
Flash DIMMs = bad idea | David Kanter | 2018/07/24 06:49 AM |
Flash DIMMs = bad idea | Michael S | 2018/07/24 06:59 AM |
Flash DIMMs = bad idea | Emil Briggs | 2018/07/24 08:29 AM |
Flash DIMMs = bad idea | Doug S | 2018/07/24 08:49 AM |
price | Michael S | 2018/07/24 03:16 PM |
price | Doug S | 2018/07/24 03:32 PM |
price | Michael S | 2018/07/24 03:49 PM |
Flash DIMMs = bad idea | blaine | 2018/12/03 04:40 PM |
Flash DIMMs = bad idea | Wes Felter | 2018/12/04 12:07 PM |
Flash DIMMs = bad idea | RichardC | 2018/12/04 04:09 PM |
Flash DIMMs = bad idea | Michael S | 2018/07/24 06:51 AM |
Flash DIMMs = bad idea | Adrian | 2018/07/24 07:35 AM |
Flash DIMMs = bad idea | Ricardo B | 2018/07/24 09:24 AM |
Flash DIMMs = bad idea | bakaneko | 2018/07/24 06:55 PM |
New article on Intel's 3DXP | Etienne | 2018/07/25 05:02 AM |
New article on Intel's 3DXP | Howard Chu | 2018/12/01 06:23 AM |
New article on Intel's 3DXP | Michael S | 2018/12/01 08:56 AM |
New article on Intel's 3DXP | anon | 2018/12/01 09:21 AM |
New article on Intel's 3DXP | Howard Chu | 2018/12/01 01:52 PM |
New article on Intel's 3DXP | Adrian` | 2018/12/01 03:43 PM |
New article on Intel's 3DXP | Adrian | 2018/12/01 11:05 PM |
New article on Intel's 3DXP | Howard Chu | 2018/12/11 05:17 AM |
New article on Intel's 3DXP | Adrian | 2018/12/11 05:42 AM |
New article on Intel's 3DXP | Maynard Handley | 2018/12/11 08:20 AM |
New article on Intel's 3DXP | wumpus | 2018/12/11 09:36 AM |
New article on Intel's 3DXP | Anon | 2018/12/11 05:21 PM |
New article on Intel's 3DXP | Maynard Handley | 2018/12/11 05:32 PM |
New article on Intel's 3DXP | Anon | 2018/12/12 12:29 AM |
New article on Intel's 3DXP | Maynard Handley | 2018/12/12 11:32 AM |
New article on Intel's 3DXP | wumpus | 2018/12/12 12:07 PM |
New article on Intel's 3DXP | Maynard Handley | 2018/12/12 12:41 PM |
New article on Intel's 3DXP | Anon | 2018/12/12 03:55 PM |
New article on Intel's 3DXP | Anon | 2018/12/12 03:49 PM |
New article on Intel's 3DXP | Anne O. Nymous | 2018/12/12 01:14 AM |
New article on Intel's 3DXP | anon | 2018/12/12 06:28 AM |
New article on Intel's 3DXP | Maynard Handley | 2018/12/12 11:26 AM |
New article on Intel's 3DXP | Anne O. Nymous | 2018/12/12 02:10 PM |
New article on Intel's 3DXP | innocent bystander | 2018/12/12 10:34 PM |
New article on Intel's 3DXP | anon | 2018/12/12 02:42 PM |
New article on Intel's 3DXP | Howard Chu | 2018/12/02 05:53 AM |
New article on Intel's 3DXP | Adrian | 2018/12/02 07:01 AM |
New article on Intel's 3DXP | Howard Chu | 2018/12/02 11:34 AM |
Intel's 3DXP availability | Etienne Lorrain | 2018/12/03 04:50 PM |