| |
NAME : HCPSXSTE
DESCRIPTION: SXS Page Management Table Entry
DSECT : SXSTE
FUNCTION : A SXS Table Entry describes one 4K page of storage
in the System Execution Space (SXS) address space.
LOCATED BY : 64-bit Host Logical (SXS) addresses:
PFXSTBLG + ((SXS Page ADDRESS / 4K) * SXSLENTH)
SXSFPNTG Field of HCPSXSTE for chained pages
SXSBPNTG Field of HCPSXSTE for chained pages
SXSFRNXTG Free storage SXSTE forward pointer
SUBANCHG SUBBK SXSTE list anchor
FRMSXSTE Field of HCPFRMTE for pages mapped in SXS
FRMSXPN Indirectly since FRMSXPN is the page
number, not the SXSTE address.
CREATED BY : HCPSXU
DELETED BY : None
NOTES : SXSTEs are contained in the SXS page management table.
Space for the SXS page management table is allocated
at system initialization and never released.
The SXS page management table is contiguous in the
SXS, but NOT in real storage. Algorithms that convert
between SXSTE address and SXS storage address must use
the SXS addresses for the SXSTE and the storage address.
There is no relationship between the real addresses.
The SXS Page Management Table (SXSTB) describes the
usage of pages in the SXS for the range from zero to
SYSSXSSZ-1. This area is referred to as the System
Execution Area. The SXSTB and FRMTB both reside
within the SXS address space but are in separate
ranges of storage above 2G. They are permanently
allocated at initialization and the usage of the
individual pages in those ranges does not change.
Therefore the SXSTB and FRMTB pages are not described
by the SXSTB.
SXSTE STATES AND STATE TRANSITIONS:
The SXSTE is used to describe the state of a single page in
the System Execution Space (SXS). Each SXS page may be
either available or in use. In addition, each page may be
backed or unbacked. Unbacked pages are never in use. Backed
pages may be either in use or available. In use and
available pages can be distinguished by whether SXSAVAIL is
on. SXSBACKD identifies which pages are backed pages.
Backed pages are associated with frames. The backing frames
reside above or below 2G in real storage. This distinction
can be determined by inspection of SXSBKB2G which is only
meaningful if SXSBACKD is on.
AVAILABLE SXS PAGES:
Available pages are "owned" by the System Execution Space
Page Manager (SXSPM). Available pages are kept on one of
three queues depending on their backing characteristics:
- available unbacked page queue (RSASXQAN)
- available backed>2G page queue (RSASXAAN)
- available backed<2G page queue (RSASXBAN)
Available SXS pages always have SXSAVAIL on in the SXSTE.
When they are on one of the available queues they can be
taken only while holding the SXSPM Queue Lock (RSASXQLK).
SXSONQUE will be on in any SXSTE that is on one of the
available SXS queues.
If SXSAVAIL is on but SXSONQUE is not on then the SXSTE is
available but is in a transition state and is currently
owned by one of the SXSPM tasks which is either in the
process of consuming it or preparing it for return to a
queue. This is referred to as the "Transitory State" and is
needed by the SXSPM to allow task ownership of available
pages for SXSPM tasks when the task must release the SXSPM
Queue Lock. Transitory SXS pages may be backed or unbacked.
In addition, a Transitory SXS page may have been allocated
to satisfy a specific deferred request. If so, SXSCPEBK
will contain the address of the CPEBK that was stacked to
complete the request. Transitory pages are not included
in the available page count (RSASXAVL) or any of the in-use
counts. The count of Transitory SXSTEs is the difference
between the total number of SXSTEs minus the sum of the
in use and available SXSTEs.
The Transitory state is also used as a stable intermediate
state within the SXSPM to reduce the complexity of state
conversions. When available SXS pages are taken from a
queue they are converted to the Transitory state. Aliases
that are removed or stolen, and CP pages that are returned
are converted to the Transitory state before any other
transition is performed. Creation of aliases and CP pages
is only done by using pages in the Transitory state. Pages
that are to be placed on the available queues must be in
the Transitory state before they are queued. Converting
between available, backed and available, unbacked pages is
only performed while the page is in the Transitory state.
The purpose for these rules is to provide consistent input
and output states for the functions responsible for making
the SXSTE state transitions.
Using information in SXSCSWRD it is possible to determine
which of these states an SXS page is in when SXSAVAIL is on:
- Transitory = SXSONQUE off, SXSBACKD "any", SXSBKB2G "any"
- RSASXQAN = SXSONQUE on, SXSBACKD off
- RSASXAAN = SXSONQUE on, SXSBACKD on, SXSBKB2G off
- RSASXBAN = SXSONQUE on, SXSBACKD on, SXSBKB2G on
This information is used in contiguous page searches to
determine whether it can take an available page (SXSONQUE
is on), and if so, which queue it needs to be dequeued
from. Pointer updates for dequeueing can be done without
knowing which queue the SXSTE is on, but update of the
counts requires knowledge of which queue it is on.
IN-USE SXS PAGES:
When SXSAVAIL is off the SXS page is considered in use.
The page may actually be in the process of being handed
out as a CP page or alias, or being returned. The counts
of in-use pages are updated when the pages are converted
between in-use pages and the Transitory state. In-use
pages are of two primary types: CP Pages and Aliases.
An alias is an in-use page that has SXSUSER on in SXSCSB0.
A CP page is an in-use page that has SXSUSER off in SXSCSB0
and SXSCP must be on if SXSUSER is off. If SXSCP is on
with SXSUSER then it is an Alias for a pageable space page,
not a CP page.
CP PAGES:
CP pages are allocated by HCPSXU during initialization for
permanently allocated pages such as the CP nucleus and the
alternate processor PFXPGs. HCPSXP allocates CP pages as
they are requested using HCPGETST, by Free Storage Manager
calls to HCPSXPFS, or by direct calls to specialized
HCPSXP entrypoints. See HCPSXP for additional information.
CP pages are guaranteed to remain resident at the same
location in real storage from the time they are allocated
until the time they are returned. They are never stolen.
In general, SXSCSB0 contains a value that matches FRMCSB0
since the associated frame must be in use for the same
purpose as the page. However, in the case of free storage
the FRMTE will have FRMCSB0=FRMFSTG while the SXSTE will
have a value in SXSCSB0 that identifies the type of free
storage that the page is currently in use as. This allows
the Free Storage Manager to convert SXS pages between types
of free storage without needing to return and re-obtain
them, or modify the FRMTE to indicate the new usage.
ALIASES:
Alias SXSTEs have no special "Alias indicator". They are
identified by SXSUSER being on in SXSCSB0 and SXSAVAIL
being off in SXSCSB3. An Alias is an SXS page associated
with a resident page of a pageable address space. It is
used to allow CP to inspect or modify the contents of the
pageable address space page as if it is part of Host
Logical storage. Aliases are created by HCPSXA when
requested by HCPHTR and HCPHTU, generally when processing
an HCPTRANS request. Aliases are generally left in place
as long as possible to reduce the need to recreate aliases
for future translation requests. Aliases can only be added
to resident pageable space pages and the pageable space
page is guaranteed to remain resident in the same frame as
long as the alias remains in place. Frames cannot be stolen
from pageable space pages without first removing the Alias.
Aliases are guaranteed to remain in place as long as the
page is last translated or locked in host logical, or if
it is a protected guest prefix page. No-owned aliases are
not allowed to be stolen.
Aliases can only be removed under the following conditions:
- SXSLKCNT=0 (not locked)
- SXSLOCKD is off (not locked)
- SXSCPLOK is off (not locked)
- SXSLTRCTG=0 (not last translated)
- SXSNOOWN is off (not no-owned) unless it is a specific
request to remove a no-owned Alias made to HCPSXARN.
- SXSPAGZP and SXSPAGZM are off (not a protected guest
prefix page)
- proper serialization is held which consists of:
- FRMTE serialization (FRMSTEAL or FRMRELSE)
- SXSTE serialization (SXSSTEAL or SXSRELSE)
- PTE serialization (SHORT or ERRSHORT)
SERIALIZED :
SXSTE serialization differs depending on the current state
of the SXSTE. The four state subsets of interest are:
- Available SXS page SXSTEs (non-Transitory) - these SXSTEs
are owned by the SXSPM and therefore serialized by the
SXSPM Queue Lock (RSASXQLK).
- Transitory SXSTEs - these SXSTEs have SXSAVAIL on so they
are owned by the SXSPM, but they have SXSONQUE off so
they are not serialized by the SXSPM Queue Lock. These
SXSTEs are in transition between states and are owned by
the task that placed them into the Transitory state. No
other task is allowed to manipulate these SXSTEs. SXSTEs
are in the Transitory state only within the SXSPM during
the processing of a specific SXSPM task. The SXSPM Queue
Lock is held while the SXSPM converts SXSTEs between the
Transitory and any other state. While this isn't always
necessary because some transitions can be done as atomic
operations, the SXSPM Queue Lock is often needed for
other reasons related to the transition such as queueing
or dequeueing or count updates. Most RSMBK counts are
serialized by the SXSPM Queue Lock to remove the need for
an interlocked update for each individual count in the
RSMBK.
- In-Use CP page SXSTEs - these SXSTEs are serialized by
the task that the page was allocated to. Often the SXSTEs
are not modified at all by the task. However, in the case
of free storage pages the Free Storage Manager maintains
information in the SXSTEs and has its own serialization
rules for updating the SXSTEs. The redefinitions below
give an indication of which fields are updated by the
Free Storage Manager. The SXSPM does not modify SXSTEs
for CP pages while they are allocated to the task.
- Alias SXSTEs - As soon as the SXSTE is marked as an Alias
it is subject to Alias SXSTE serialization rules so the
Alias is created in a serialized state. Serialization of
Aliases uses SXSTE-specific serialization defined in
SXSCSB3. The Alias serialization states of SXSTRANS,
SXSRELSE and SXSSTEAL are mutually exclusive and provide
an indication which type of task holds serialization and
clues about the transitions that may occur. Although
SXSAVAIL is in the same byte as the serialization bits,
it does not provide serialization but rather that the
SXSTE is either available or in the Transitory state and
different serialization mechanisms apply. The SXSCSB3
serialization bits apply only to Aliases and should
never be on when SXSUSER is off or SXSAVAIL is on.
- SXSTRANS - a translation type task is manipulating the
Alias. Since Aliases are only created as the result of
a translation request, they are created with SXSTRANS
already on via an atomic transition from the Transitory
to the Alias state.
- SXSRELSE is used during release processing when Aliases
are removed or made No-owned. The No-owned Manager also
uses SXSRELSE when reclaiming the No-owned Aliases.
- SXSSTEAL is used when an alias is being stolen by the
SXSPM or being removed so that a frame can be stolen
by the Frame Manager.
The creation and destruction of Aliases requires SXSTE,
FRMTE, and PTE serialization for the page which the
alias is being created or destroyed. See HCPPGSER MACRO
prolog for rules for obtaining serialization when PTE
serialization is also needed. SXSTRANS is also used by
translation and locking services for existing aliases.
When Aliases are destroyed they are converted to the
Transitory state in an atomic operation with SXSTE
serialization on initially, but off afterwards.
RELOCATION CONSIDERATIONS : None
COMMENTS :
The definition of the SXSTE was derived heavily from the
FRMTE to minimize impact to functions that manipulated
information in the FRMTE but were changed to use host
logical storage and SXSTEs instead. These functions are
free storage, page translation, release processing,
steal, etc. While there are significant similarities,
there are subtle but important differences, especially
in the area of serialization. Some fields in the SXSTE
are in different locations than they were in the FRMTE in
previous releases For example, SXSLTRCTG and SXSLKCNT are
in the first word of SXSSTATEG. Fields that exist in both
the SXSTE and FRMTE are at the same displacements.
While SXSTEs are on an available list they retain some of
the state information from the prior usage, but may not
remain associated with the backing frame. When aliases are
removed they must be disassociated from the FRMTE. When
CP pages are returned and the available backed page queue
is at capacity the backing frame is removed. In both cases
the SXSTE is placed on the available unbacked SXS page
queue until it is reused. Although the backing frame has
been removed, the SXS PTE will be invalid but will still
contain the PFRA of the frame that the SXS page was last
associated with. The frame may still contain useful data,
however there is no guarantee that the frame has not been
reused after it was disassociated from the SXS page.
Several fields that exist in the SXSTE are for diagnostic
or performance reasons:
- Diagnostic information:
- SXSRET14 contains the callers return address for
CP pages that have been returned and the SXSTEs have
not been reused. It can be useful in diagnosing cases
where a page was expected to still be in use but had
already been returned.
- SXSOBT11 contains the R11 value (may be VMDBK) at
the time of the obtain of a page with SXSCSB0=SXSCP
and the CP page is still in use. It can be useful in
diagnosing cases where it appears SXS pages are not
being returned, or a page contains different contents
than expected.
- SXSOBT14 contains the callers return address from
the time of the obtain of a page with SXSCSB0=SXSCP
and the CP page is still in use. It can be useful in
diagnosing cases where it appears SXS pages are not
being returned, or a page contains different contents
than expected.
- SXSCPEBK contains the address of a CPEBK that is being
re-driven and has been given this SXSTE to use to
satisfy the deferred request. This information can be
used to determine whether Transitory SXSTEs are lost.
- Performance short-cuts
- SXSSXPTE contains the address of the SXS PTE for
available and Transitory SXS pages. It is used to
quickly locate the SXS PTE when validating or
invalidating the SXS PTE for the page. It is also to
quickly obtain the backing frame address for backed
available pages by getting the PFRA from the PTE.
- SXSFRMAD is used to pass the address of the backing
frame to HCPFRF when allocating a new free storage
page to avoid the expense of an LRAG instruction.
| |