Browse Prior Art Database

Provider Caching using hold polling of configuration state bit-mask Disclosure Number: IPCOM000225781D
Publication Date: 2013-Mar-05
Document File: 2 page(s) / 26K

Publishing Venue

The Prior Art Database


A method for provider caching using hold polling of configuration state bit-mask is disclosed.

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

Page 01 of 2

Provider Caching using hold polling of configuration state bit -mask

Disclosed is a method for provider caching using hold polling of configuration state bit-mask.

Caching in a hardware provider can have distinct performance advantages. As such, it is highly desirable to have a provider cache.

However, keeping a provider cache coherent can be a challenge. One key problem is that all updates do not come through a single management point, so the provider must often refresh cache from the device itself. An example of this might be a Common Language Infrastructure (CLI) script running that does not go through the provider. In addition to this, device state configuration can change due to actual physical actions, for example, replacing a disk drive.

A further challenge is the lack of event notification from the firmware device itself. In the presence of only a polling mechanism, how is the cache coherency maintained efficiently?

A provider caching mechanism that does not thrash, does not return stale data, and efficiently deals with firmware is done using a hold polling algorithm. The provider issues a polling request that the firmware holds until it detects a change. Polling response is simply a bit field to indicate the area of the device management data that has changed. Anti-thrashing is done by holding off, for at least a polling interval, changes by the firmware.

Given the overhead associated with firmware, provider caching is needed. As a general guideline, this caching should prevent routine provider queries from turning into expensive firmware calls that might, for example, drive one or more I/O commands to disk. Additional caching may be needed simply due to the slowness of firmware queries in order to meet performance requirements of Common Information Model (CIM) clients. There is no requirement to comprehensively cache every CIM data field it supports. However, for fields it has collected in the past that change, it must refresh data that has become stale. The data that is cached needs to be stored in such a way that there is a proper balance between memory efficiency (since caching takes up memory) and performance.

There are several ways that the CIM data can change: hardware can be changed, different management interfaces (like CLI) might be employed, another provider might be used, or perhaps the provider with the cache may receive a request (like a create volume request). Many caching schemes employ a write-through, but given the various sources of change, an approach that goes through the firmware is utilized. When a CIM Client comes in with a request that updates the write cache, the pro...