Browse Prior Art Database

Method of Storing Into Non-Ex Lines With Processor Priority Multiprocessor Caches

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

Publishing Venue

IBM

Related People

Liu, L: AUTHOR

Abstract

A technique is described whereby multiprocessor (MP) caches are provided a method of storing into non-EX lines with processor priority. Described is a token concept for fast stores into Read-Only (RO) lines in MP caches with EX locking.

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

Method of Storing Into Non-Ex Lines With Processor Priority Multiprocessor
Caches

      A technique is described whereby multiprocessor (MP)
caches are provided a method of storing into non-EX lines with
processor priority.  Described is a token concept for fast stores
into Read-Only (RO) lines in MP caches with EX locking.

      In MP cache designs, EX locking is often used to facilitate the
stores from processors.  However, there are often penalties incurred
due to stores into non-EX lines. The concept described herein
provides a processor state in which a processor is allowed to store
into its non-EX cache lines without waiting for the EX authorization
from storage control (SC).  The descriptions are based on a write
synchronous architecture, similar to the IBM System/370.  It is
assumed that the MP design is equipped with EX locking. Each entry in
a cache may have three states: INV, RO and EX. All L1 caches are
store-thru to the next level of memory hierarchy (e.g., L2).  The
concept also lends itself to store-in designs.

      Stores into RO lines will be called Fetch-No-Data (STRO)
requests.  In more conventional designs, a STRO  will need to acquire
EX status on the line in order to perform stores unconditionally
(e.g., the store or later accesses need not be backed up in any
case).  Such status acquiring will cost performance.  This STRO costs
are more serious in some MP designs with larger caches (e.g., using
RO-aggressive schemes). However, it is essential to find the
conditions in which the central processor (CP) may store
unconditionally. Consider the following:
      P1            P2
  Store   ARO    Store   BRO
  Fetch   ARO    Fetch   BRO
  Fetch   BRO    Fetch   ARO

      At the beginning, both A and B are RO in both caches. If both
CPs can do the stores unconditionally, architectural violations may
occur since the last fetches on both CPs could get pre-store data.
The problem here is that both CPs store without any serialization in
notifying the remote sites.  In more standard designs, such
serialization is performed at the SC through STRO requests and the
CPs are not allowed to store unconditionally until receiving
acknowledgement from the SC.

      The architectural violations may be avoided if at most one CP
in the system is allowed to perform stores unconditionally at any
moment.  That is, all stores from such a CP are considered
pre-synchronized at the SC and the results may be observed without
confusion.  In some sense, all lines are regarded EX as far as stores
are concerned (although there could be more copies of the lines in
remote caches).  The concept described herein differs from
conventional EX locking in that the EX states are on storage blocks.

      The concept introduces processor priority for stores. There is
a token S in the whole system.  At any moment of time, the token can
be held by at most one CP.  The CP holding the t...