Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

System RAM to survive reboot or OS crash

IP.com Disclosure Number: IPCOM000030473D
Original Publication Date: 2004-Aug-17
Included in the Prior Art Database: 2004-Aug-17
Document File: 2 page(s) / 44K

Publishing Venue

IBM

Abstract

Many of the benefits of persistent store can be achieved at much lower cost by ensuring that reserved parts of volatile system memory are not reset on reboot. We can see a huge performance enhancement at low cost and with very little loss of reliability; this requires minor changes to BIOS, optional changes to operating system, significant changes to middleware and none to applications

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 2

System RAM to survive reboot or OS crash

Persistence has always been the underpinning to reliable computing, where resources (results) are expected to survive failures. Typically, persistence has been provided by hard drives; which usually survive most kinds of failures such as power outage or system crash. Where this is not reliable enough, mirroring, remote mirroring etc is used.

    An alternative is battery backed RAM or state preserving memory. This is used for example in some disk caches (either providing temporary persistence until the data can be forced to disk, or permanent persistence), or Zos coupling facility. These tend to be expensive solutions.

    As hardware and software (and even power infrastructure) get more reliable, there is increasing interest on solutions giving a slightly lower level of persistence/reliability at greater speed and a lower cost. [The level available from a 'lower' level today is probably higher than the level that was achieved from a higher level previously.]

    The proposal is to permit reserved parts of standard system RAM survive a reboot, and to make the middleware aware of and able to exploit these changes. This is similar to the Rio Cache [reference below] with more emphasis on the middleware aspect.

    This will require a change to the BIOS, to inform it how to treat the memory on reboot. In particular, which part of the memory is reserved and should not be reset.

Preferably, there will be
a) interaction between the BIOS and the operating system to manage this reserved area
b) interaction between the operating system and middleware (or other applications) to manage and share the reserved area
c) change to the middleware to use its part of the reserved area.

    Alternatively, the reserved area will be hidden from the operating system and 'ordinary' programs that inquire how much memory is available.

    There will be a special BIOS enquiry that makes the reserved area available to programs written to understand it. eg combine (a) and (b) above.

    This may provide a useful interim solution in cases where it is easier to upgrade hardware and middleware than it is to upgrade operating systems. Presentation to middleware: ========================

    The reserved area may be presented to the middleware as standard mapped memory, and used with normal memory instructions. For full (to the level of this technology) reliability this will either require (a) that the reserved area uses writethrough caching from the processor cache to the m...