Conceptually the CPU counter in a meter runs continuously when any domain inferior to it is executing instructions. The illusion is maintained only because looking at counters in meters is mediated by the kernel which is in charge of the illusion. Meter keys to superior meters are involved as are the counters there. Prepared domains hold a cache of CPU time that has been deducted from each of the superior meters. The logical value of a counter in a meter is thus its real value plus the sum of the CPU caches in the inferior prepared domains. These prepared domains are easily found for the meter keys therein are involved and the backchain thru such keys locates all of the prepared domains referring directly to a given meter. Meters directly inferior to a given meter are also found via backchain. A tree walk efficiently locates all of the prepared domains where CPU caches borrowed from a given meter may be found.

A real meter counter is never allowed to go negative. When a running domain exhausts its cache it seeks to borrow a few seconds more by going up the meter chain and deducting the proposed advance from each meter. If one of the real meter counters is less than this, then it will settle for whatever is there. In one of the real meter counters is zero then it tries to recall some caches from sibling domains under that zero meter.

Each prepared meter has a bit called dry indicating that there are no prepared domains with positive CPU caches thereunder. This avoids the cost of repeatedly walking sub-trees of meters that have already been scavenged for CPU cache. It handles fairly well the case of two conversing domains under a big tree of prepared but otherwise inactive domains. If they are both under a meter that is running dry then they will fight over the dregs of that meter’s supply, but at least not need to repeatedly visit all of the inactive prepared domains.

When a domain invokes a node key to fetch the number key in a counter slot of a meter, the kernel notices that the slot is involved DR. Upon closer examination the kernel notices that the slot is in a meter. We could sum the inferior caches in the prepared domains, but we currently unprepare the meter which causes all of the caches thereunder to be recalled. The domains remain prepared but they will have to reestablish their caches before they run again.

Note that meters can be rescinded, permanently by deleting, or temporarily by setting a counter in a meter to zero.

See this section for even more detail. In an initial pass towards the prime meter key we follow meter keys as we acquire exclusive locks on the meter nodes. If we meet a node already exclusively locked we look to see if it was us who locked it. If so we report a meter bug, release our exclusive locks and go on to other work. If it is another processor, then we release our exclusive locks and look for other things to do (look on ready queue (=CPUQUEUE)). If we come across a node prepared as a meter key we know there is a path of involved keys to the prime key.

Every prepared meter knows the distance to the prime meter key. We thus enforce the meter depth limit.

See also this for the reason we used the wired model of CPU resources rather than the simpler battery model.