Method of Storing Into Non-Ex Lines With Processor Priority Multiprocessor Caches
Original Publication Date: 1991-Apr-01
Included in the Prior Art Database: 2005-Apr-02
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.
Method of Storing Into Non-Ex Lines With Processor
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.
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:
Store ARO Store BRO
Fetch ARO Fetch BRO
Fetch BRO Fetch ARO
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.
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.
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...