Repository navigation
srv4 memory upgrade - #8971
srv4 memory upgrade#8971briansrls wants to merge 2 commits into
Conversation
…ratio, not two editable literals gunbc.runner_slot_allocation declares cores_per_slot = 8 and memory_max = 16 GiB as independently editable literals. Nothing relates them, so editing either silently changes the shape's CPU:memory ratio and no consumer can tell -- the second-representation defect DESIGN section 2 names, one concept with two places to change it and no derivation between. The replacement is an ANCHOR plus a RATIO. Memory is the anchor because 16 GiB is the figure this fleet has actually run; cores are derived. The anchor's carrier says in its own field that it is arbitrary and expected to move, because an arbitrary value that does not say so becomes indistinguishable from a derived one once the author leaves. THE RATIO IS CITED, AND ITS EVIDENCE ARM IS THE POINT. extdeps.cloud.ubicloud already carries five arm64 rows -- 2/6, 4/12, 8/24, 16/48, 30/90 -- every one exactly 3 decimal GB per vCPU, with the vendor stating each arm64 vCPU is a DEDICATED physical core, so vCPU and core are one unit and the ratio carries without a threading adjustment. But '1 core : 3 GB on Arm' reads like an architectural law and is not one: Azure's Ampere Altra families quote about 4 GiB/vCPU general-purpose and about 8 GiB memory-optimized. So the evidence coproduct separates PublishedProviderCatalog (this vendor sells these shapes) from OperatorAdoption (we DECIDED to price ours the same way) from NormativeStandard (a document says it should be) -- and the third arm is deliberately uninhabited rather than filled with the strongest-sounding available claim, which would be rung inflation applied to a citation. The adoption row records that it crosses a hardware boundary: the cited rows are Altra Q80-30 and this fleet is Altra Max M128-30. DECIMAL GB, NOT GiB, AND THE DIFFERENCE IS A SLOT. The vendor writes '48GB'; runner_shape_census deliberately returns the per-vCPU figure on the basis-less arm because a quotient of two quoted figures is a figure in that same unit. 3 GB is 2.79 GiB -- about 7%, which at fleet scale is a whole slot -- so the bytes are explicit and the quoted numeral and unit label are kept beside them. CORES ROUND UP, WHICH IS FAIL-CLOSED AND NOT THE OBVIOUS DIRECTION. 16 GiB at 3 GB/core wants 5.73. Rounding DOWN to 5 packs more slots onto a host and gives each less CPU than its memory deserves -- the host admits more work than the shape justifies. Rounding UP to 6 admits fewer. The count derived from this shape is a capacity ADMISSION, so the error that over-admits is the one that hurts. WHAT THE ADOPTION EXPLICITLY DOES NOT TAKE: the same cited rows carry disk_bytes (200 GB at 8 vCPU, 300 GB at 16). Those rows price standalone VMs that own their disks; a gunbc slot shares one host filesystem with every other slot, the OS, shared caches and swap. Adopting the quoted figure would price ~22 slots at 4.4 TB against a 457 GB device and refuse the fleet to two slots while appearing faithful to the citation. Recorded as a decision so a later author does not 'complete' the adoption. Verified green by execution: 6 cores derived, an exact multiple does not over-round (24 GB gives 8, not 9), and a non-positive per-core figure refuses rather than yielding a zero-core slot that downstream counts would divide by. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…eader criticizes Three findings, all correct. THE SECOND ONE IS THE REAL DEFECT AND IT IS EMBARRASSING. MemoryPerCore carried bytes: ByteSize BESIDE quoted_numeral and quoted_unit_label with nothing deriving either from the other, so byte_size(3000000000) and (3, "GB") could silently disagree. That is one measured quantity with two independent literals -- a fork, not provenance -- which is precisely the second-representation defect this module exists to remove from the fleet's slot shape, reproduced inside the fix for it. The repair is to REUSE extdeps.ci_runner.types QuotedByteMagnitude rather than restate it, and the reused carrier is strictly better than what it replaces: it states the basis as a CONSTRUCTOR (decimal gigabytes, binary gibibytes, or a vendor figure with no stated basis) and its resolution REFUSES on the basis-less arm instead of guessing. Bytes are now derived through quoted_magnitude_bytes and cores_for_anchor returns a CoreCountResolution that can refuse -- an arm the first cut could not express at all, because an unresolvable quote had no representation and would simply have been whatever the bytes field happened to say. A DISCRIMINATING RED CAME WITH IT, because the obvious assertion does not discriminate: 16 GiB at 3 GiB/core is 5.33 cores and rounds to 6 exactly as 3 GB/core's 5.73 does, so a cores == 6 claim passes under either basis. The claim now uses a 12 GiB anchor, where decimal gives 5 and binary gives 4. If the basis is ever dropped, that goes red. THE FIRST FINDING: arm_profile_storage_not_adopted_note was a bare String whose sole purpose was commentary, which DESIGN 4c rules out in as many words -- no Accepted program can read one, so it was machine-invisible authority dressed as data. The storage exclusion is now a typed axis list on the adoption itself: OperatorAdoption carries adopted_axes, this adoption carries [CpuMemoryRatio], and a consumer reaching for per-runner storage is told no by the model rather than by a comment. The reason it matters is unchanged -- Ubicloud's rows carry 200 GB at 8 vCPU beside the ratio, and copying it would price ~21 slots at over 4 TB against a 457 GB device -- but it is now a fact rather than a paragraph. THE THIRD: dag/test/parsecheck2.dag was exactly what it looked like, a scratch compile entry. Deleted. The claims live in test.claim.runner_shape_profile_witness_test under names that say what they check, enrolled where witnesses are discovered. Verified green by execution: all five claims pass, including the basis red and the basis-less refusal. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
All three findings from The second one is the real defect, and it is the one worth naming plainly. The repair is to reuse A discriminating red came with it, because the obvious assertion does not discriminate. 16 GiB at 3 GiB/core is 5.33 cores and rounds to 6 exactly as 3 GB/core's 5.73 does — so Finding 1 — correct, and §4c says it in as many words: no Finding 3 — correct, and it was exactly what it looked like: Verified green by execution: all five claims pass, including the basis red and the basis-less refusal. |
|
Closing as superseded, not abandoning the idea. #8976 merged the CPU:memory ratio as What is genuinely superseded here:
What is scratch and must not land: What is worth re-landing, cleanly, on main: This branch also carries the branch-mixing I disclosed earlier (files from — sent from warm-tern-755 |
1 participant
Replaces two independently editable literals with one anchor plus a cited ratio.
gunbc.runner_slot_allocationdeclarescores_per_slot = 8andmemory_max = 16 GiBas separate rows. Nothing relates them, so editing either silently changes the shape's CPU:memory ratio and no consumer can tell — one concept with two places to change it and no derivation between (DESIGN §2). This lands the derivation: memory is the anchor, cores follow.Operator decisions this encodes (2026-08-23): 16 GiB stays the anchor and is explicitly arbitrary and expected to move; the CPU:memory ratio is 1 core : 3 GB adopted from Ubicloud's standard arm profile; the shape lives in the compute fabric.
Four things worth reviewing closely:
The evidence arm is a coproduct, and the strongest arm is deliberately empty.
PublishedProviderCatalog(this vendor sells these shapes) is separated fromOperatorAdoption(we decided to price ours the same way) fromNormativeStandard(a document says it should be). No normative standard is known for Arm CI runner ratios — Azure quotes ~4 GiB/vCPU general-purpose and ~8 memory-optimized on the same Altra silicon — so1 core : 3 GBis a market profile, not an architectural law. Filling the standard arm would be rung inflation applied to a citation. The adoption row also records that it crosses a hardware boundary: the cited rows are Altra Q80-30, this fleet is Altra Max M128-30.Decimal GB, not GiB, and the difference is a whole slot.
runner_shape_censusdeliberately returns the per-vCPU figure on the basis-less arm, because a quotient of two quoted figures is a figure in that same unit. 3 GB is 2.79 GiB — ~7%, which at fleet scale moves the count. Bytes are explicit with the quoted numeral and unit label kept beside them.Cores round UP, which is fail-closed and not the obvious direction. 16 GiB at 3 GB/core wants 5.73. Rounding down to 5 packs more slots onto a host and gives each less CPU than its memory deserves — the host admits more work than the shape justifies. The count derived from this shape is a capacity admission, so the error that over-admits is the one that hurts. Asserted both ways: an exact multiple must not over-round (24 GB gives 8, not 9).
Ubicloud's
disk_bytesis explicitly NOT adopted, recorded as a decision rather than left as an omission. Those rows carry 200 GB at 8 vCPU and price standalone VMs that own their disks; a gunbc slot shares one host filesystem with every other slot, the OS, shared caches and swap. Copying the figure would price ~22 slots at 4.4 TB against a 457 GB device and refuse the fleet to two slots while appearing faithful to the citation.Disclosed, because it is the thing to judge: this carrier has no production consumer yet. Its consumer is the per-host count derivation that replaces the
5/5/6/6literals inhost_memory_admitted_width, which is not in this PR because it is a structural move rather than a line edit —gunbc_runner_slots_per_hostsits upstream of the overhead/session/headroom charges it needs, so making it real means relocating it downstream and repointing 9 files. DESIGN §6 treats a new artifact with no final consumer as presumed scaffold, so that presumption applies here and I am not arguing it away: the question for review is whether this lands now with its consumer following, or waits and lands together. I have no objection to the latter.Verified green by execution — 6 cores derived from the 16 GiB anchor, exact multiples do not over-round, and a non-positive per-core figure refuses rather than yielding a zero-core slot that downstream counts would divide by.