This design is more like the simple charge sets (p2,soon-sets) than like the full charge sets (chrgset). The idea is to use Bloom filters to represent sets statistically.
The Scheme
Establish charge sets as they are now {for simple CS's} but allocate just one page to represent the set.
If domain under set s references a page or node with CDA = c then turn on bit h(c) in the page representing set s.
Otherwise the scheme is identical to the current simple charge sets.
They provide for high speed "set synergy tests".
The scheduler can read the set representation for these sets and in a simple and fast routine determine the size of unions of the various subsets of S. The scheduler can then select "compatible subsets" of S which will fit in core together {taking into consideration shared pages and nodes} and allocate a time for them to run.
The keeper may also have an invalid meter, but the unchargeable activity cannot be infinite because of the following argument. If a keeper is not a gate, we don't call it. If it is a start key, the keeper becomes busy. If it is a resume key, the key is deleted. So with each jump, the number of available domains plus the number of resume keys decreases, but cannot go negative.
As an added precaution against unchargeable activities interfering with chargeable ones, the resourceless domain is put at the end of the CPU queue before it traps.
Once the kernel caused no such traps. It was changed because invalid meters were a common symptom of programming bugs and the change made it easier to find such bugs.
One problem with the current design is described at (p3,badmet).
Another problem is that the current design interferes with the following strategy which is otherwise the only solution to a problem that I describe here.
If the design of the guard were changed slightly to include a meter node reference, the guard could "shut down power" by deleting the meter as its initial action and thus terminate the actions of the object before it had taken any undesigned actions.
This assumes that all of the domains of the object act under the indicated meter. This is at least frequently easy to arrange.
The current kernel scheduler is extremely crude. Every 200 ms the running job is placed at the end of the CPU queue and then the first member of that queue is started {(slice)}. No domain is immune to time slicing.
The best that can be easily argued for this scheme is that it is easy to understand and that programs that use little time are unlikely to be sliced frequently. Its simplicity leads to low overhead.
The problem: Suppose domain D provides a quick public service and many domains call it frequently.
How serious is it that D will occasionally be sliced? Would the system indeed be better if D were not sliced?
If there were no external schedulers, CPU bound domains would share the CPU equally.
There are a number of considerations which mitigate toward other policies. Meters were invented, in part, to implement such policies. Can meters solve this problem also?
It seems most likely that the callers of D will be within some scheduling entities.
Adhere to externally specified policies on responsiveness by certain applications.
Suppose that each of the three meter counters has a new state that is entered when exhaustion causes some domain to trap and that that a counter in that state will not cause further traps. This might take just a few commands in the kernel and save both complexity in schedulers and overhead. This state would be logical.
If the keeper replenishes the meter then when the keeper returns to the resume key that he holds the first member of this stall queue will be placed on the CPU queue. Two of the domains under this meter will thus be quickly restarted. Other members will wait, however, for the worrier. This seems to be an undesirable effect that is difficult to program around.
I propose a capability very much like the RETURNER that is implemented in the kernel, which places all members on the jumper's stall queue on the CPU queue. This key would be useful by being called or returned to.
Segment keepers may have similar needs for such a key. In general any program that removes an impediment from other programs could use such a key.
There is another anomaly with meter keepers in that they do not get to see order code kt. This is so that existing meters without a keeper will respond to the kt call.
One solution would be to define the "no-call" bit for the meter which would cause the meter key to reply with kt+2 to any order code but kt. Perhaps also M(kt;==>6;M1) would produce a meter key like M except with the "no-call" bit.
I have deinstalled the explicit meter call stuff until we arrive at and implement some such solution.