Browse Prior Art Database

Method for non-hierarchical hardware object model locking

IP.com Disclosure Number: IPCOM000245839D
Publication Date: 2016-Apr-13
Document File: 7 page(s) / 96K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is an algorithm to lock a static hardware object model hierarchy in a non-hierarchical fashion, which proves to be substantially faster than hierarchical locking.

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

Page 01 of 7

Method for non-hierarchical hardware object model locking

In enterprise-class servers that have associated firmware responsible for server boot-up and other functions, the various hardware components of the server (processors, memory, nodes, etc) need to be modelled in software (this is usually termed as a Hardware Object Model, or HOM) so that various firmware applications have an interface to access (read/write) hardware. Firmware is typically multi-threaded on large servers, meaning there could be contention to access the same hardware, and this needs to be serialized via a lock on the hardware's object model.

The HOM lock, behind the scenes, is just a mutex (a means of serializing access) which would be an attribute of each model that represents a unique piece of hardware. Various threads of firmware applications would need to lock such a mutex to gain exclusive access to the hardware. The HOM lock needs to be hierarchical to honor the parent-child hardware hierarchy : a lock request on the entire system (termed as System lock) would mean locking each and every hardware modelled, which would be all the nodes, processors. memory, cores etc; an exclusive processor register access request would require locking the processor and all its children such as cores, caches, etc.

Given this hierarchical nature of the HOM, the HOM lock adds a substantial firmware delay to procedures that need to lock various hardware components for exclusive access. Examples of such procedures are server boot, hardware dump collection, etc. For eg on a four-node enterprise-class server, a system lock would need to lock the mutex corresponding to the System, and all the mutexes corresponding to every other hardware under the system - this amounts to locking around 3000 mutexes, which takes about half a second today with known implementations. Take a server boot or initial program load (IPL) for example, which would involve many such System locks and other hardware locks, there is a considerable adverse impact on the boot performance. Another example is hardware dump collection in case of hardware failures, this is another use-case that needs a large amount of processor locks.

Disclosed is an alternate approach to the hierarchical HOM locking described above. This alternate approach proves to be much faster than the conventional locking approach, hence it helps alleviate the delay introduced by the conventional HOM locking approach.

The core idea is to avoid traversing each and every entity in the HOM and acquiring a mutex lock for the same. Instead, pre-defined bits are set to indicate which parts of the System are locked for exclusive use. This proves to be much faster than the conventional approach.

As described earlier, typical approaches to lock a HOM for a specific hardware, say the entire System, would mean acquiring a lock on every HOM instance that is a child of the system HOM. For example, a processor HOM lock typically would mean locking the pro...