Browse Prior Art Database

An Application Level, Non-Volatile Memory Management Mechanism

IP.com Disclosure Number: IPCOM000146570D
Publication Date: 2007-Feb-16
Document File: 5 page(s) / 67K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method that provides a generalized solution for managing non-volatile storage across power events. It can be used when non-volatile memory solutions are integrated into existing DRAM solutions. Benefits include supporting multiple, independent applications.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 43% of the total text.

An Application Level, Non-Volatile Memory Management Mechanism

Disclosed is a method that provides a generalized solution for managing non-volatile storage across power events. It can be used when non-volatile memory solutions are integrated into existing DRAM solutions. Benefits include supporting multiple, independent applications.

Background

Currently, the only non-volatile memory available to the application software is through the hard disk drive (see Figure 1). As memory-based, non-volatile solutions become available, mechanisms will be necessary for applications to allocate, re-acquire, and manage this memory. No standard application level mechanisms currently exist, especially to support multiple, independent applications.

General Description

Non-volatile (NV) storage accessed through standard memory interfaces is similar to volatile memory with the following exceptions. It requires:

§         A method of identifying the storage across power events

§         Support for multiple, independent applications from a single non-volatile memory pool

§         Must be considered a “scarce resource”. The memory management mechanism must be available to identify “lost” allocations, free lost allocations, and recover unused allocations.

§         A method of establishing exclusive ownership of the storage through authentication

An application that requires persistent storage calls NVMalloc with a GUID, that is associated with the allocated non-volatile block of memory. The NVMalloc call also includes a size (in bytes), the address of a callback routine to notify the application of changes in the NV storage system, a value that indicates how long the application will require the persistent storage, and a flag to indicate whether the requested size is fixed or flexible.

An application considers NV memory a scarce resource and treats it accordingly. Typically, an application consolidates all NV-related parameters into a compact data structure, and allocates a single block of NV storage. The NV utility manages the pool of NV blocks by performing garbage collection to consolidate any contiguous blocks, and deleting blocks whose lifetime has expired. A block whose lifetime has expired is considered “lost” and is freed. If the callback for the block is valid, it is called before the free operation is preformed. This allows an application to extend the lifetime of the block, if necessary.

The callback associated with a block is considered invalid after a power event; however, the GUID is persistent. An application that allocates an NV block before a power event, can call NVMalloc after the event to recover the pointer to the NV memory. If an existing GUID is detected in an NVMalloc call by the NV utility, then the original pointer is returned. If the GUID is unknown to the NV utility, then a new zeroed block is allocated.

The key claim...