General Points

The kernel controls three resources directly: CPU, channels and main storage. The channels are used mainly to copy pages and nodes to main storage when they are needed, and to copy them back when the main storage is needed for others. In an operating system such as Gnosis there are trade-offs between storage and channel time. If a page is unused for a minute or so it is usually advisable to keep it on the disk. For much shorter periods of time it is advisable to let the page remain in main storage. The user's program may be a partner in managing this trade-off.

Meters serve the same function as accounts on other systems and several others as well. An analogy between a Gnosis meter and an electric meter is instructive. Meters measure the quantity of resources that programs use as an electric meter measures electricity used. Meters may be used to prevent programs from proceeding as a switch on the electric power can be used to halt the progress of some machine. Cutting off a meter, however, does not destroy data. The meter may be turned on again in such a way that the affected programs restart where they left off. Electric distribution systems may be viewed as trees with the generating equipment at the root and the consumers at the leaves and with meters at the nodes of the tree. A similar structure will emerge below for our meters.

A meter key is a specific type of key that designates a node. A meter is a node viewed through a meter key.

{ni}The node must have the gratis {(gp)} attribute.

A node key will yield a meter key {(p2,node)}. The meter key to this node suffices to use the node as a meter. The meter key restricts the holder to using the node as a meter. Meters are used in domains {(d1)}, segments {(memdepmt)} and other meters {(depmet)}. This chapter describes only what the Gnosis kernel knows about meters.

See (d1) for details concerning the ultimate use of meters and requirement of domains for them.

Slot 1 of a meter node designates another meter node with a meter key. The first meter is said to (_depend on) the second meter. If meter A depends on meter B then A is said to be (_inferior) to B and to meters to which B is inferior. Any resource measured by a meter is also measured by the meter that it depends on {and by all the meters to which it is inferior}.

A process whose domain depends on {(p1,d1)} a meter node causes the counters in that meter node to count the use of resources by the process.

{ni}If a segment node depends on {(p1,memmet)} a meter node, the channel counter and main storage counter in the meter node count the cost of bringing and holding in core, the pages under the segment node.

The primordial meter is a valid level 0 meter. If meter B satisfies (meterformat) and slot 1 holds a meter key to A and A is a valid meter of level N and 0<=N<=19 then B is a valid meter of level N+1. The previous two sentences describe all valid meters.

{ni}The node must have the gratis {(gp)} attribute.

In other words, a valid meter must {among other things} be the head of a chain of nodes via slot 1 of those nodes, that leads to the primordial meter. This chain may involve only meter keys and may have at most 20 keys.

See (p1,badmeter) about trying to use an invalid meter.

Meter Keepers

There are three cases where an implicit jump is made to a slot in a meter due to activity in the programs below the meter. In two of these cases the program that gets control receives a node key to the meter and this node key has the same databyte as the meter key. In each of these two cases if the key in the slot is a memory or meter key the effect is as if it had been a DK(0).

Exhausted Resources

When some one of the three counters in a meter node is zero and a process tries to decrement it the key in slot 2 of that meter node is implicitly called. The call is as if JUMP G2(m;,,NK,REX) had been executed {if G2 is not a memory or meter key}. NK is a node key to the meter {with a databyte of 0}, REX is a restart key to the process under the meter, and m is -1, -2 or -3 depending on which counter was exhausted. The channel counter causes a fault when it reaches 30; the only faults allowed thereafter are those required to start the meter keeper.

{arcane}{ni}Charge Set Size Too Big
{arcane}LOOSE END: limit should be in charge set!

The data key in slot 8 of the meter node is a limit on the size of the charge set. The first 24 bits are the node limit and the next 24 bits are the page limit. Different Gnosis implementations will have their own internal maximum limits for pages and nodes. If either limit specified exceeds the internal limit for the implementation, the corresponding limit in the data key will be reduced to the internal limit when the charge set in the meter is used.

If this limit is attained the key in slot 2 is implicitly jumped to as JUMP G2(code;,,NK,REX) where NK is the node key to the meter and G2 is the key in slot 2 of the meter node {but see above}. REX is a restart key to the domain that tried to exceed the limit. If code = -16 then the node limit was exceeded, if code = -17 then the page limit was exceeded. See also (p2,removepage).

{arcane}LOOSE END: What if I decrease the limit to below the c.s. size while no process is under the c.s.

{arcane}{ni}Wait for Idle Charge Set
If a meter designates a charge set and if the last domain under that charge set that is in the running state leaves the running state and the first bit of the data key in slot 15 of the meter key is 1, the key in slot 9 of the meter is jumped to if it is a resume key. No parameters are passed.

LOOSE END: What if the only running domains are stalled?

Explicit Jumps to Meters
M(kt;==>6;).

{arcane}{ni}{This will not be implemented until the problems of (p1,tj) are solved. It is needed for multiplex meters {(p3,muxmet)}.} If M is a meter key and c isn't kt then the jump M(c...,...;K1,K2,K3,K4) has the effect of the jump G2(d...,...;K1,K2,NM,K4), where NM is a node key to the meter M. G2 is the key in slot 2 of M unless that key is a memory or meter key, in which case G2 is DK(0). d is c with the left bit turned off. {This prevents the meter key holder from confusing the meter keeper about whether the call was implicit or explicit.} If G2 is a memory or meter key, it behaves in this context as DK(0).

Slot 0 holds DK(0).

Slot 1 holds a meter key to the superior meter {(p1,mhier)}.

Slot 2 holds the gate key to the meter keeper {(p1,m2)}.

Slot 3 holds DK(CPU counter) where CPU counter < 256**11. {(p1,m3)}.

{ni}Slot 4 holds the channel counter {(p1,m4)}.

{ni}Slot 5 holds the main storage counter {(p1,m5)}.

Slot 6 holds DK(0).

Slot 7 holds DK(0) or the charge set key {(p1,m7)} {or the simple charge set key {(p2,soon-sets)} for now}.

{ni}Slot 8 is a data key that provides limits on the charge set size {(p1,m8)}.

{ni}Slot 9 holds the gate of the vacancy waiter if any {(p1,noproc)}.

Slots 10, 11 and 12 are reserved for future functions and must hold DK(0).

Slots 13 and 14 are available to the user for any purpose.

There is a convention for slot 14. We can distinguish two somewhat different motivations for limiting the CPU counter in slot 3.
One is to limit the resources used by domains to specified values for billing, performance monitoring or other reasons.

The other is to prevent domains from executing altogether. This is typically for debugging or to stop a runaway domain from doing damage.

In order to reduce the interference between these two uses of the CPU counter, there is a convention. When the CPU counter is stopped for the second reason, the unused CPU resource is saved in slot 14. See for example (p3,meter14).

{ni}Slot 15 holds a data key that currently controls whether there is a vacancy waiter {(p1,noproc)}.

A new meter is created by merely creating a new node, formatting it as a meter and placing a meter key in slot 1 and then making a meter key from the node key {(p2,node)}. The new meter is as good as the meter that it points to unless one of the balances is smaller.

{arcane}{nonref}Meter Design Notes