Browse Prior Art Database

Storage Control Function Optimized for Processor Performance

IP.com Disclosure Number: IPCOM000104856D
Original Publication Date: 1993-Jun-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 2 page(s) / 71K

Publishing Venue

IBM

Related People

Frey, BG: AUTHOR

Abstract

Some computer architectures rigidly define the image of storage (memory) and the elements which map it, often to simplify the job of programming tasks which interact, either as processor and I/O, or as multiple processors in a multiprocessor system. In many cases, these architectures include hardware support to accelerate or simplify the task of manipulating the image of storage. Examples include instructions which implement TLB shootdown in an MP (e.g., S/370 IPTE) and instructions which bring a page in from a backing store (e.g., S/370 PGIN). Often the execution of instructions of this sort have no significant result other than the manipulation of the storage image.

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

Storage Control Function Optimized for Processor Performance

      Some computer architectures rigidly define the image of storage
(memory) and the elements which map it, often to simplify the job of
programming tasks which interact, either as processor and I/O, or as
multiple processors in a multiprocessor system.  In many cases, these
architectures include hardware support to accelerate or simplify the
task of manipulating the image of storage.  Examples include
instructions which implement TLB shootdown in an MP (e.g., S/370
IPTE) and instructions which bring a page in from a backing store
(e.g., S/370 PGIN).  Often the execution of instructions of this sort
have no significant result other than the manipulation of the storage
image.  It is also typically the case that these instructions are
slow, owing either to widespread communication, searching of mapping
structures, or movement of large quantities of data.  Since the code
which manipulates the storage image is typically packaged separately
from that which operates on the modified image and there can be
significant latency in the transition, there is substantial
performance to be gained from making, what had been, a synchronous
operation an asynchronous operation.  Some architectures have learned
from analysis of the performance of these synchronous instructions
and created new instructions which perform the operations
asynchronously.  For those architectures which would like most of the
benefit of an asynchronous operation without creating new
instructions, it is possible to enhance the hardware implementation
to function asynchronously while appearing synchronous.

      In implementations which support manipulation of the storage
image in hardware, there is typicall...