Browse Prior Art Database

Storing in Multiprocessing Systems

IP.com Disclosure Number: IPCOM000119988D
Original Publication Date: 1991-Mar-01
Included in the Prior Art Database: 2005-Apr-02
Document File: 3 page(s) / 117K

Publishing Venue

IBM

Related People

Amos, J: AUTHOR [+6]

Abstract

The concept of management of a memory hierarchy evolved from the uniprocessor and the two-way TCMP (Tightly Coupled MultiProcessor) configuration. This is not the best way to attack the problems associated with high levels of MP. It becomes apparent that the purpose served by a static form of exclusivity is inappropriate in a system that misses (due to invalidation) on a considerable percentage of previously stored into lines. Thus, exclusivity is wrested from the owner before it has done any good.

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

Storing in Multiprocessing Systems

      The concept of management of a memory hierarchy evolved
from the uniprocessor and the two-way TCMP (Tightly Coupled
MultiProcessor) configuration.  This is not the best way to attack
the problems associated with high levels of MP.  It becomes apparent
that the purpose served by a static form of exclusivity is
inappropriate in a system that misses (due to invalidation) on a
considerable percentage of previously stored into lines.  Thus,
exclusivity is wrested from the owner before it has done any good.

      What is required is a more dynamic form of exclusivity which
allows a processor to complete a single store from instructions like
{ST, STC, CS, OI,...} and then relinquish exclusivity.  Such a
capability extends naturally to a series of stores originating from a
single instruction, such as an STM (Store Multiple) or an MVC (Move
Character), and depending on the dynamics of the pipeline, extend to
two distinct instructions that are close enough in the instruction
sequence and store into the same cache line.

      The basis for the management of this dynamic exclusivity
involves bits that are set and maintained within the directory of the
cache and within the pending store buffer of the processor.

      Consider the case where the processor attempts to store in a RO
line.  The STORE PRETEST which is issued devolves to the SCE which
determines, based on the number of copies of this RO line in other
caches, that a dynamic exclusivity should be granted to this request.
Let us call the dynamic exclusivity EXCLUSIVE/REQUESTED and the
corresponding status for all other copies of the line in other caches
will be called INVALID/REQUESTED.

      For lines that have been granted EXCLUSIVE/REQUESTED status two
bits are to be set.  The first bit will be in the directory of the
cache to indicate this special sub-status of exclusive so that the
store put-away of all stores to this line will be broadcast to all
cache that have INVALID/REQUESTED versions of this line and and that
the store put-away of the last store from the processor to this line
will return the line to RO status in all caches where this store
updates the line.  The second, the bit maintained by the pending
store buffer, will establish which store put-away to the line is to
be designated as the last store.

      For a simple single store case, the put-away associated with
the STORE PRETEST is the last store.  In the case of multiple stores
orig inating from a single instruction, the final store put-away to a
particular line is designated as the last store.  All intermediate
stores are broadcast to all caches because of the bit set in the
cache directory but it is only the final store which resets the
status of all lines to RO.  If a line-match occurs between a store
that has just been AGENED and a store that is within the pending
store buffer, the last store designation passes to the conceptually
later store....