Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Design for a Backing Storage for Storage Protection Data

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

Publishing Venue

IBM

Related People

Chencinski, EW: AUTHOR [+2]

Abstract

This article pertains to a mechanism for holding Storage Protection (SP) data, as described in the System/370* architecture. The design solves the performance problem caused by implementing the SP array in the same DRAM technology used in the main storage (MS).

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

Design for a Backing Storage for Storage Protection Data

      This article pertains to a mechanism for holding Storage
Protection (SP) data, as described in the System/370* architecture.
The design solves the performance problem caused by implementing the
SP array in the same DRAM technology used in the main storage (MS).

      The SP array contains a data entry for each 4K byte page of MS.
The SP data consists of a key, a fetch protection (F) bit, a
reference (R) bit and a change (C) bit.  The implementation used in
the past contains an SP array constructed of the chip technology used
in the cache. This uses critical space in the performance-sensitive
center of the machine, which is justified by the possibility that the
SP data can be inspected or altered on every access to the L2 or the
L3.  The major drawback is that SP real estate limitations prevent
expansion of MS.

      This SP real estate problem is solved by moving the entire SP
array onto slower and cheaper technology.  Speed matching is done by
providing an SP cache (SPC) that holds the most frequently used SP
data.  The SP data that is not in the SPC is held on a card
similar to the L3 array cards. This card, called the SP Storage (SPS)
has the same kind of DRAMs that are used by the L3.

      It is required that the SPS provide keys at a faster rate than
the MS can fetch lines from new pages, otherwise, the performance of
the system would be degraded.  Consider an MS with N way interleaving
on a double line basis.  This MS can fetch N different double lines
from N different pages (needing N different keys) at the same time.
This creates an SP performance requirement that is a potential
problem for a single card SPS design.  Note that the SPS cannot be
interleaved on the same basis as the MS.  This is because the SPS
entries each cover one page, while the interleaving in the MS is done
on 1/16 of a page.

      Castouts from the SP have similar performance requirements,
because there is normally an SP castout with every SP key fetch.  The
performance of the 3 KEY OPs - SSK, ISK and RRB, are not affected by
the interleaving of the MS. Because of their infrequent nature, their
performance is not critical.

      In summary, using DRAMS to implement the SP array solves a real
estate problem, but creates a performance problem.  This article
describes a solution to that problem.
The Solution

      The figure shows a conceptual view of the SPS.  The SP data is
divided into 2 parts, the KEY-F bits and the R-C bits.  These two
types of data are each handled uniquely. The KEY-F bits are
duplicated N times in N independent arrays.  Each of these arrays has
enough entries to cover the entire MS address space.  A fetch from
the SPC can go to any of the N copies of the KEY-F array to
get the data it needs, so up to N fetches can be serviced
simultaneously. The KEY-F portion of the SPC has been made store
through because SSK is the only operation...