Browse Prior Art Database

Interrupt disabled lock optimization for a Micro-partitioned environment Disclosure Number: IPCOM000128878D
Original Publication Date: 2005-Sep-20
Included in the Prior Art Database: 2005-Sep-20
Document File: 2 page(s) / 26K

Publishing Venue



When running with virtualized processors (shared processor partitioning), traditional spin locks can be inefficient. In particular, spin locks which disable interrupts and then acquire the lock historically do not allow the caller of the locking routine to be undispatched if the lock has contention. In this mechanism, a locking process is started and aborted and restart it to keep lock contention from stalling the system indefinitely.

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

Page 1 of 2

Interrupt disabled lock optimization for a Micro -partitioned environment

Studying performance problems using operating systems and shared processor partitioning, it is apparent that nuances of Hypervisor dispatching can have huge impacts on partitions which span multiple virtual central processor units (CPU's). More specifically, most operating systems are designed around the concept of spin locks. Spin locks are used to serialize data access from a number of processors (or threads, such as hardware multi-threading (HMT) or Simultaneous multi-threading (SMT)). These locks are designed around the premise that the access to data under the lock is fairly quick. Thus, if a lock acquisition fails, there is a busy wait or "spin" until acquiring the lock. Many other optimizations have been added to spin locks, such as spinning for a limited time and then undispatching. Some spin locks also require serialization against access to the lock by interrupt handlers. These are referred to as disabled locks. Disabled locks semantically involve both disabling interrupts (either physically or logically) as well as taking the lock. One consequence of this semantic is that, once there are disabled interrupts, one usually can't undispatch the sequence of code that initiated the lock acquisition.

In a shared processor partition environment, the tenet that spin locks are help only briefly cannot be held. In fact, most Hypervisors have no knowledge of what is running in a partition. Thus, there are frequent cases where a lock is acquired on a virtual processor, then the virtual processor is undispatched for milliseconds time. During...