Each meter node has three counters each of which is a data key. These counters count down as the resources are used. They are:

CPU

This is the time devoted by the CPU to executing the instructions of the program plus some estimate of the time required to do the system calls on behalf of the program. This estimate does not depend on factors outside the user's control. CPU time is measured by the (_CPU counter) in slot 3 of the meter node. The unit is one microsecond/16.

The channel is required when a page or node is referenced that had not been recently referenced. The charge set {(p1,chrgset)} defines the recently referenced pages and nodes for purposes of repeatably estimating resource use. These events are counted. The page or node is added to the charge set when this happens. Channel time is also charged when removing a page or node from a charge set {perhaps only if the page has been modified}. Channel usage is counted by the (_channel counter) in slot 4 of the meter node.

See (p2,soon-sets) for function available now.

This is the integral, over (_time or) headway {(p1,headway)}, of the size of the charge set {(p1,chrgset)}. Main storage usage is measured in units of page-microseconds by the (_main storage counter) in slot 5 of the meter node.

Headway

Unlike some definitions of the term "headway" we include actions that can be reproducibly attributed to the program, such as faults out of the charge set. Headway is a linear combination of the following:

A linear combination of CPU time {as measured by the meter}, and page and node faults out of the charge set.

(_Elapsed time, when the meter is designated by a segment node. The meter is under a charge set and the size of that set determines the meter rates.)

(_A page fault for a page under a segment node with a meter. The charge set is that of the faulting process.)

Head Scratch Time

To account for periods where there is no process under a charge set, headway is counted in the same node as the charge set until a process runs under the meter again. The rate of headway {headway per unit of elapsed time} in this case is several times smaller than the headway rate when a CPU is running a domain under the charge set. Charge set depletion will normally cause the cost of this headway to go to 0.
{arcane}LOOSE END: What if main storage counter runs out during this time?

{ni}The Charge Set
See (p2,soon-sets) for current abbreviated function.

General Points

The charge set key is an external handle for an internal construct that is the system's memory of which data the program has accessed recently. The charge set depicts a set of pages and nodes. The charge set is used to measure the utilization of main storage and channels by the user's program. Normally accessing a page or node that is not in your charge set causes the page or node to be added to the charge set at the expense of the program's meter. {See (p1,gp) for the exception.} Accessing pages or nodes already in the charge set is not measured by any meter.

When a jump occurs, the jumpee's domain root and meters may be added to the jumper's charge set. {Can't charge them to the jumpee until the new meter is intact.}

Some meters have a charge set key in slot 7. Such a meter node is said to (_hold) a charge set. A meter is said to be (_under) a charge set if the meter holds the charge set or holds no charge set but depends on a meter under the charge set. The primordial meter holds a charge set and thus every meter is under just one charge set. A domain is under a charge set if the meter it designates is under the charge set. An action by the process in that domain that uses a page or node {other than a gratis page or node {(p1,gp)}} that is not in the charge set causes that page or node to be added to the charge set at the expense of the domain's meter.

If a node of a memory tree is a segment node that depends on {(p1,memdepmt)} a meter then that node is under the same charge set as the meter. Otherwise a node or page of a memory tree is under the same charge set as the node of the memory tree that designates it. If a page or node is designated by more than one memory tree slot it may belong to more than one charge set, but it will not belong to one charge set twice. The root of a memory tree is under the same charge set as the domain.

Some pages and nodes are (_gratis). Such pages and nodes need not belong to a charge set in order to be accessed. See (p2,gratis-use) for other ramifications.

When a page or node of a charge set has been unused after some amount of headway it will be removed from the charge set. This amount is implementation dependent.

{arcane}Implementation Compromise
Future implementations may compromise the way they determine whether a page is in the charge set if that page is in a shared segment. Section (p1,chrgset) requires that two users sharing a segment (_that holds no meter key) cannot share a page table to that segment. The initial implementation does not share a page table in this case and as a result does not confuse whose charge set a shared page belongs to.

On the other hand:
Suppose that:
Meters don't share charge sets; in fact, a meter either has a charge set or not; there are no charge-set keys.

Segments have meters and thus charge-sets {as now officially specified},

Then page tables under different charge sets need not be shared because:
The heavily shared segments will be under their own meter and thus under their own charge-set.

In this scheme a page or node might be under a meter with a charge-set that is itself under a meter with a charge-set and thus under two charge-sets.

We must decide whether it is important for different meters to hold the same charge-set.

There seems to be two ideas here that might be separated:

Pages and nodes under more than one charge set. This seems to be allowed by the proposal that two meters not hold the same charge set.

Using meters {and thus chargesets} in red segment nodes to handle the shared page table problem.

Calls on charge set keys
CS(0==>n,tod) "count pages" where CS is a charge set key, n is the number of pages in the charge set, and tod is the TOD clock value when the charge set was last activated.

CS(1==>n,(8,tod)) "count nodes" where CS is a charge set key, n is the number of nodes in the charge set, and tod is the TOD clock value when the charge set was last activated.

CS(2==>0) "reset charge set" where CS is a charge set key clears all pages and nodes from the charge set and automatically re-activates the charge set.

Programming Note
If there is more than one process under a charge set it is unlikely that the meter readings will be reproducible.

{ni}Boolean Sets
These are some ideas that help a scheduler distinguish when two of its clients are sharing pages. This idea supports the measuring of charge sets and even estimating the size of intersection of charge sets {thus the name"boolean"}.

A Variation

How about the following scheme:
When the set is activated assign a fixed size hunk of real memory whose size is some power of two. Initialize it to 0.

When some page is to be added to the set hash its CDA into some bit offset into the hunk and turn on that bit. {Ignore whether it was on.} When Order code 0 is done on the charge set key return the bit count adjusted for the expected number of conflicts. {I will look up the formula.}

Advantages
Always fast to add a page.

There is never an overflow.

Less code {I think}.

Disadvantages
Approximate

Defeatable {but we could change the hash algorithm occasionally and defeat any attack that I can think of.}

A Further Variation
Suppose that the bit vector were passed back to the charge set holder -- call him "sched". Sched could then test for synergism very quickly. By counting the OR of the vectors of some set of jobs, sched could quickly determine the feasibility of holding those jobs in core at once.

This is some sort of violation of information hiding but:

Sched doesn't keep such information for long periods of time. {Thus replacing CDA's would still be feasible.}

Its being wrong is not catastrophic.

We only need one scheduler and thus need not spread the CS keys far. Indeed we might wrap the SCS key in a domain wherein this kernel data is hidden while providing "synergy measures" -- a classic application of abstract types {and operations thereon}. This is what we do with the KID in order to ameliorate the existence of the UNSPEC key.