mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-09 14:02:56 +09:00
Myasnikov Daniil
920ab73d10
TEMPORARY, investigation only, same throwaway branch, never merged. lscpu reports this class as 32 MiB of L3 in two instances, eight cores to a domain. That is what the hypervisor ADVERTISES. The sibling map was advertised too and the arms already here showed it to be real; nothing has ever tested the cache map, and every claim about a sandbox node straddling two L3 slices rests on it. Neither side of the stack answers it. OCI documents the OCPU-to-core relation and confines NUMA and BIOS tuning to bare metal, stating no CCD or NUMA alignment guarantee for VM shapes anywhere; the launcher in cncf/automation sets no PlatformConfig at all, so nothing asks for alignment and nothing reports what was granted. Whatever the placement engine did is what we got. The discriminator is capacity contention between two DISTINCT physical cores, so SMT is not in this at all -- that was the previous experiment. Each worker walks its own dependent chain over its own array, built after it pins so the pages are its own rather than a copy-on-write share, and the footprint is swept across the advertised domain size and half of it. Two cores sharing a domain must fit two footprints in one cache; two on different domains get a cache each. A real split separates the curves at half the working set; curves lying on top of each other mean the split is not something our guests pay for. The chain is `i = arr[i]` over a multiplicative permutation, which is a dependent load: the next address is unknown until the current one returns, so no prefetcher can run ahead, and the footprint is exactly four bytes per slot. Verified locally to resolve the hierarchy, 0.018s at 1 MiB against 0.056s at 32 MiB over the same step count, and to refuse rather than guess on a machine that advertises a single domain. Assisted-By: Claude <noreply@anthropic.com> Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>