Resource aware scheduling
Note: the functionality described on this page will be available in GeoDMS 20.10.0 or later. It is experimental and off by default.
When a configuration requests many results at once, the GeoDMS starts as many calculation operations in parallel as the multi-threading settings allow. Each running operation claims memory for the arguments it materialises, for its working data and for its results. On wide workloads, starting many large operations together can drive the combined claim past the available physical memory, causing paging or memory-allocation failures.
Resource-aware scheduling places an admission gate in front of operation starts. Before an operation may start, its predicted memory footprint — its results, what it materialises of its arguments, and its working memory — is booked in a ledger of running operations. When the booked total would exceed a budget, the start is deferred until running operations have released memory; a deferred operation is also retried when nothing else runs, so progress is never blocked. Operations for which no prediction is available are never withheld.
modes
| mode | registry value | effect |
|---|---|---|
| off | 0 | (default) no ledger, no gate |
| shadow | 1 | the ledger is kept and every admission decision is logged (“would defer”), but nothing is actually withheld |
| enforce | 2 | admission is enforced: an operation that would overrun the budget is deferred and retried later |
The mode is set in one of three ways:
- with the GUI (GeoDMS 20.11.1 and later): Settings > Local machine options > Parallel Processing, the q (shadow) and Q (enforce) check boxes. The two are modes of one setting, so ticking one clears the other; with neither ticked the feature is off. See Local machine Options dialog;
- with the registry value ResourceAwareScheduling, see (Registry) Settings;
- per run with the command-line options /Sq (shadow) and /SQ (enforce); /Cq or /CQ switch it off. These are accepted like the existing /S1../S3 multi-threading options, see User Guide GeoDMS RUN.
Shadow mode is the recommended way to explore the feature: the log then shows which operations would have been deferred and by how much the budget would have been overrun, without changing any scheduling.
current limitations
Enforce mode is not yet a reliable way to lower the peak memory of a calculation, which is why it is off by default. Two effects limit it on large models:
- Not all memory is visible to the gate. The prediction covers the memory the GeoDMS allocates itself. Memory that a geometry library allocates internally — for instance while buffering polygons or determining polygon connectivity — is not part of it, so on geometry-heavy configurations the gate can underestimate what the process really holds.
- Postponing only helps for memory the postponed operation itself would claim. Much of the memory of a large model is claimed by chains of operations that have already started, tile by tile. Refusing to start one more operation does not release that memory, and once the budget is already exceeded the gate has to let work through anyway, since otherwise the calculation could not finish at all.
On a large land-use model, enforce mode therefore postponed a very large number of operation starts while the peak memory stayed the same as without it. On configurations built from many independent, comparably sized operations the effect is better. Measure with shadow mode first, and treat a lower peak as something to verify per configuration rather than to expect.
the budget
By default the budget is derived from the machine: the physical memory times the MemoryFlushThreshold percentage (default 80%), the same threshold that governs the memory-flushing wait procedure. The registry value SchedulerBudgetMB — or the command-line option */SB
size predictions and declared knowledge
Predictions are made from the calculation rules before any result exists, on a confidence ladder: where data is ready, counts and sizes are exact; otherwise the engine derives what it can from the rules, and falls back to an assumed default where it cannot. For data-dependent cardinalities — subsets, sparse origin–destination matrices — the modeller often has cheap knowledge the engine cannot derive. Two properties on a Domain unit declare it:
- SizeUpperbound — a sound upper bound on the element count; admission may reserve memory based on it;
- SizeExpectation — a point estimate of the element count; informs cost estimates and ordering, never reserved on.
Declarations are planning aids only: a declaration that turns out wrong degrades scheduling quality, but never invalidates any calculated result.