Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!uvaarpa!mcnc!gatech!hubcap!mark
From: mark@hubcap.UUCP (Mark Smotherman)
Newsgroups: comp.arch
Subject: hardware support of reference and change bits
Message-ID: <1458@hubcap.UUCP>
Date: 20 Apr 88 21:38:35 GMT
Organization: Clemson University, Clemson, SC
Lines: 71
Keywords: page replacement reference bit change bit


In reviewing hardware support for page replacement policies, I see that
IBM mainframes allocate the reference(/accessed) bit and the change(/dirty/
modified) bit in the storage key associated with the physical page frame.
On the other hand, modern microprocessors (e.g. 80386, NS32082 MMU) allocate
these bits in the page table entry.  The tradeoff seems to be extra opcodes
on the IBM versus slightly larger page table entries and some increase in
memory traffic (and invalidate signals) for the microprocessors.

On the IBM (XA), three instructions operate on the reference and change bits:
RRBE - reset reference bit extended, SSKE - set storage key extended, and
ISKE - insert storage key extended.  RRBE does the obvious, SSKE can be used
to reset the change bit, and ISKE places a copy of the storage key and
reference and change bits in a specified register.  The reference and change
bits are also set by any channel operations.

I don't have any hardware manuals available for the 386 or 32082 that give
full descriptions, but I assume they work in the following way.

1. Given the absence of the page table entry from the TLB:
  * Upon a reference, the page table entry is brought into the TLB and
    the reference bit is inspected.  If the reference bit is zero, then
    it is set to one.  This update of the entry must be done in a store-
    through manner.  That is, not only the should the TLB copy of the page
    table entry be updated, but the copy of the entry in the cache should
    also be updated.  (Of course, a designer could eliminate the inspection
    of the reference bit during a critical path by performing the store-
    through each time.)  An additional store-through to main memory and
    cache invalidate signal would be needed in a multiprocessor.  There
    would not be a need for a TLB invalidate signal.
  * Upon a change, the page table entry is processed as above, only with
    both bits set to one.  The condition causing memory traffic is if
    either bit is zero (00, 01, or 10).

2. Given that the entry is currently in the TLB:
  * A reference has no effect, since to be in the TLB the reference bit
    must already be set.
  * Upon a change, the update of the page table entry must be done in a
    store-through manner only if the change bit in the TLB is not already
    set to one.  (Eliminating this inspection would seem to relatively
    expensive in terms of the additional memory traffic.  Aren't writes
    about 30% of memory operations, as a rule of thumb?)

3. Immediately after an instruction changes a page table entry (e.g. reset
the reference or change bits), the TLB must be purged.  For multiprocessors
the cache must also be purged (or the change must have been a store-through)
and invalidate signals sent to the other processors to purge their TLBs and
caches.

For those who know, is this truly how things work?  Do you have any idea
(or better yet, any measurements) of the amount of memory traffic involved
in the setting of the reference and change bits?  Can I/O processors (DMA
or whatever) on these micros affect these bits?


P.S.  The IBM XA Principles of Operation manual gives an unusual disclaimer
on the reference bit:  "The reference bit may be set to one by fetching data
or instructions that are neither designated nor used by the program, and,
under certain conditions, a reference may be made without the reference bit
being set to one.  Under certain unusual circumstances, a reference bit may
be set to zero by other than explicit program action." [p. 3-11, March 1983
edition of SA22-7085-0]  The first case would appear to be caused by
prefetching that crosses page boundaries (e.g. branch target buffers).  The
other two cases elude me.
--

Mark Smotherman, Comp. Sci. Dept., Clemson University, Clemson, SC 29634
INTERNET: mark@hubcap.clemson.edu    UUCP: gatech!hubcap!mark
-- 
Mark Smotherman, Comp. Sci. Dept., Clemson University, Clemson, SC 29634
INTERNET: mark@hubcap.clemson.edu    UUCP: gatech!hubcap!mark