Browse Prior Art Database

Store Lookaside Directory at Second Level Cache

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

Publishing Venue

IBM

Related People

Ignatowski, M: AUTHOR [+2]

Abstract

Disclosed is a mechanism for reducing second level cache directory lookup frequencies when store-thru first level caches are used in a multiprocessor (MP) system. The basic idea is to record cache coordinates at storage control element for those recently stored cache lines.

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

Store Lookaside Directory at Second Level Cache

      Disclosed is a mechanism for reducing second level cache
directory lookup frequencies when store-thru first level caches are
used in a multiprocessor (MP) system.  The basic idea is to record
cache coordinates at storage control element for those recently
stored cache lines.

      Consider a MP system with 2 level cache hierarchies as depicted
in the figure.  Each processor has a first level cache (L1) that
store- thru to a second level cache (L2) shared by all processors.
Upon an L1 cache miss the cache line is fetched from L2, which may,
in turn, cause an L2 line fetch (from main storage) if an L2 miss
occurs.  All data stores from each processor are sent to L2 for
putaway, which require the data block to be resident there.  L2 is
managed by the storage control element (SCE).  In such a system,
especially with more processors, the handling of stores may become a
major burden at L2/ SCE.  Presumably, each store will require L2
directory lookup for putaway. When there are more processors, L2
directories may need to be duplicated in order to handle the frequent
lookups.  We observe that stores from a processor tend to hit few
storage blocks in short time windows (i.e., store has spatial
locality).  Small lookaside directories for stores may be used for
recording L2 coordinates, so that most store putaway at L2 need not
involve directory lookup.

      Let the Main Storage (MS) be partitioned into fixed size
blocks.  The block size needs not be equal to but is typically an
integral multiple of L2 line size.  In the following, for brevity of
description of the ideas, we assume that the block size is identical
to the L2 line size. We consider, at SCE, a Store Lookaside Directory
(SLAD) Si, for each processor Pi.  Each Si is structured as a
set-associative directory or simply as a stack of entries (depending
on the replacement policy and the geometry). Each entry of Si
contains the following fields:

      ADDR   COORD   TAG where ADDR is the (absolute) block address,
COORD is a representation for the location in L2, and TAG contains
necessary flags (including a valid bit).  The SLADs are completely
managed by the SCE in the following manner:
      (1)  When a store from Pi arrives at the SCE/L2, it is matched
against Si.  If a hit occurs in Si, the associated COORD is used to
determine the L2 array position for putaway.  If a miss occurs, the
L2 directory is looked up and a new entry is created in Si with
proper information (e.g., ADDR and COORD), and the store is putaway
accordingly.  In the process, if the L2 line is not found (i.e., L2
...