============================================================================== MVPS -- Kernel Profile (Proposal) A companion proposal for instantiating the three-layer coherence framework with vantages defined inside the operating-system kernel. Leonardo Melegassi Catellix Research Version: 0.1 (proposal -- not yet implemented on a running kernel) Date: 2026-05-21 Status: companion to MVPS_THREE_LAYER_MATHEMATICAL_EVIDENCE.txt v1.1 and to MVPS_DATAPLANE_PROFILE.txt v0.1 ============================================================================== Abstract. This document proposes a *kernel profile* of the MVPS three-layer coherence framework defined in MVPS_THREE_LAYER_MATHEMATICAL_EVIDENCE.txt (the math companion, v1.1). The observatory profile composes MVPS bundles from external probes; the data-plane profile composes them from forwarding silicon state; this profile composes them from *internal kernel observers* implemented as eBPF programs, perf counters, ftrace tracepoints, or equivalent in-kernel telemetry hooks. The central kernel claim is that *the algebraic structure of v1.1 holds when the vantages are kernel data-structure observers rather than network endpoints*. Specifically: the same axes C_1, C_2, C_3, the same operational Hamiltonian H, the same Mahalanobis phase distance Phi_D, and the same operational phase label Phi_K are produced -- but now from a bundle whose vantages are the kernel scheduler queue, the IRQ subsystem, the socket layer, the page allocator, and the block-I/O queue, each observing a *different projection of the same kernel state*. Together with the observatory profile (external prober) and the data-plane profile (forwarding silicon), this completes a three- surface witness of a single conjecture that runs through the whole framework, and that is articulated formally in the companion document MVPS_UNIFIED_STATE_SPACE.txt: there exists an algebra of "operational coherence" that is invariant under substitution of vantage type, across the layered abstraction stack from physical packets at the wire through CPU instructions inside the kernel. The kernel profile is the most testable surface for that conjecture, because eBPF instrumentation is mature, ubiquitous on Linux, and produces reproducible per-tick state at sub-millisecond resolution on commodity hardware. A reference implementation here would, on its own, falsify or sharpen the unification claim faster than the silicon-bound data-plane profile. Three honest framings used throughout this profile. (a) Nothing in this document has been implemented as a running eBPF program on a real kernel. It is a design proposal grounded in published Linux kernel internals (Bovet & Cesati, Love), the eBPF reference (Gregg 2019), and standard perf/ftrace/bpftrace idioms. A reference implementation and in-kernel validation are listed as open work in Section 9. (b) The worked example in Section 5 (a coordinated kernel-level degradation under memory pressure + IRQ saturation + scheduler imbalance) is *synthetic*. It is constructed from published fault-injection studies (Filebench, stress-ng, schbench) and from operating-system textbook descriptions of pathological interactions between subsystems. It does not describe a specific real incident. (c) This profile is a *proposal for a future companion I-D* and is not, by itself, an Internet-Draft submission. It exists to test whether the framework's axiomatic abstraction extends inward to the operating-system kernel without algebraic change. That test, combined with the data-plane profile, provides the empirical basis for the unification argument in MVPS_UNIFIED_STATE_SPACE.txt. Companion artefacts: - MVPS_THREE_LAYER_MATHEMATICAL_EVIDENCE.txt v1.1 (mathematical reference) - MVPS_DATAPLANE_PROFILE.txt v0.1 (the silicon-vantage sibling of this profile) - MVPS_UNIFIED_STATE_SPACE.txt v0.1 (the formal claim that unifies all three surfaces) - draft-melegassi-ippm-mvps-bundle - https://catellix.com/v11-evidence.html ============================================================================== 1. Problem statement: the kernel sees more than it tells ============================================================================== Modern Linux kernels expose an enormous amount of state to userland observers: - /proc/stat, /proc/loadavg, /proc/diskstats, /proc/meminfo - perf events (hardware + software + tracepoints) - ftrace and dynamic tracing (kprobes, uprobes) - eBPF programs attached to tracepoints, kprobes, XDP, sk_msg, sched_ext hooks, and per-cgroup observers - cgroup v2 accounting (cpu, memory, io, pids) - perf top, bpftop, biolatency, runqlat, profile, offcputime These signals are consumed by tools that operate per-subsystem: vmstat for memory, iostat for I/O, perf for CPU, ss for sockets, mpstat for IRQ distribution. Each tool delivers a *projection* of kernel state through one observational hook. The operational reality is that *kernel degradation rarely occurs in a single subsystem*. A memory-pressure event triggers reclaim, which triggers I/O, which saturates the block layer, which back- pressures the socket layer, which depresses TCP throughput, which the network stack reports as elevated retransmits, which the user sees as application slowness. The same event is visible -- with different leading latencies and different signal-to-noise ratios -- in at least five subsystems. Operators today correlate these *symptom streams* manually, after the fact, using tools that each see a different shadow of the same dynamic. The kernel profile reframes the problem: instead of N independent subsystem monitors, compose a *bundle* B_k(t) from N kernel vantages, each observing a different subsystem at tick t, and compute (C_1, C_2, C_3, H, Phi_D, Phi_K) on that bundle. The kernel is then no longer a collection of unrelated counters but a single dynamical object whose *coherence collapse* is the leading indicator of cross-subsystem degradation. This is the same move that the observatory and data-plane profiles make at their respective layers. The difference is locality of observation: the kernel profile observes the substrate on which the data-plane and observatory profiles themselves run, and is therefore the *innermost* surface available to MVPS short of hardware microarchitecture. ============================================================================== 2. Vantage transformation: from probe / next-hop to kernel observer ============================================================================== 2.1 Kernel vantage V_i. A kernel vantage is an in-kernel program -- typically an eBPF program attached to a tracepoint, kprobe, sched_ext hook, or perf_event -- that updates a small per-vantage state record at every tick boundary. The recommended canonical set of five vantages, covering disjoint kernel subsystems with well-known cross-coupling: V_sched : scheduler vantage. Observes run-queue length per CPU, runqueue latency (per-CPU sum of (run-time minus wakeup-time) for tasks descheduled during the tick), and per-CPU idle fraction. Hook: sched_wakeup, sched_switch tracepoints. V_irq : interrupt vantage. Observes interrupt count per IRQ vector and per CPU, softirq time per CPU, and IRQ-handler latency histogram. Hook: irq_handler_entry/exit, softirq_entry/exit tracepoints. V_mm : memory vantage. Observes page-allocation rate per zone, direct-reclaim latency histogram, OOM-near indicators (low-watermark crossings), and per-cgroup memory.pressure. Hook: mm_page_alloc tracepoint, vmscan_direct_reclaim_* tracepoints, cgroup v2 PSI counters. V_blk : block-I/O vantage. Observes per-device request-queue depth, I/O latency histogram, and merge/split rates. Hook: block_rq_insert/issue/complete tracepoints. V_sock : socket / network-stack vantage. Observes per-flow CWND, srtt, retransmit count, and the per-socket sk_pacing_rate distribution. Bridges to the data-plane profile when the host is itself a forwarding element. Hook: tcp_retransmit_skb, tcp_send_loss_probe kprobes; sk_msg eBPF hooks. Minimum recommended N = 3 (typically V_sched, V_mm, V_blk -- the three subsystems most tightly coupled under degradation). N = 5 is the standard profile. 2.2 Per-vantage state record. Each vantage maintains, in BPF map storage, four streams during the tick (Delta_t default: 100 ms; configurable down to 10 ms on modern kernels): (a) Distribution sketch p_i. A Count-Min sketch (4 hashes x 256 buckets x 16-bit counters) over the vantage's primary key: - V_sched : (cpu, runqueue-latency-bucket) - V_irq : (cpu, irq-vector-bucket) - V_mm : (zone, allocation-order-bucket) - V_blk : (device, latency-bucket) - V_sock : (flow-hash, cwnd-bucket) Storage: 2 KiB per vantage. (b) Latency estimator rtt_i. A 32-bit fixed-point estimate of the dominant per-event latency observed in the tick (run-queue wait, IRQ handler, reclaim time, I/O completion, or TCP smoothed RTT depending on vantage). (c) Touched-object set S_i. A Bloom filter (4096 bits, 5 hashes) over hash-coded references to kernel data structures the vantage interacted with during the tick: - V_sched : per-CPU runqueue addresses - V_irq : (cpu, vector) pairs - V_mm : zone + numa-node bitmask - V_blk : (device, queue-id) pairs - V_sock : (sk address-hash, NUMA node) Storage: 0.5 KiB per vantage. (d) Counters. Event count, error count, throttle/back-pressure count. Total per-vantage state: ~3 KiB. Total for the N = 5 canonical bundle: ~15 KiB plus ~2 KiB of shared lookup tables. Negligible compared with the kernel's own working set on any host that runs a userland. 2.3 Tick boundary. The bundle B_k(t) is closed at tick boundaries by a userspace reader (per-CPU perf-ring drain) or, in higher-frequency profiles, by an in-kernel scheduler timer running an eBPF program in BPF_PROG_TYPE_PERF_EVENT mode. The MVPS computation itself (Sec. 3) runs in userspace on the drained state at every tick. ============================================================================== 3. Axes restated for kernel vantages ============================================================================== The definitions below cite MVPS_THREE_LAYER_MATHEMATICAL_EVIDENCE.txt v1.1 Secs. 2.1-2.3 verbatim. Only the *instantiation* changes; the functional forms are unchanged. --------------------------------------------------------------------------- 3.1 C_1 -- causal coherence (kernel-causality bound + temporal stability) --------------------------------------------------------------------------- In the observatory profile, C_1^Einstein measures violations of the *physical* speed-of-light bound on RTT. In the kernel profile, the analogous bound is *kernel causality*: an event that depends on another cannot be observed before its prerequisite, and the propagation delay between subsystems is bounded by kernel scheduling and locking quanta. C_1^Einstein (kernel variant). For a vantage pair (V_a, V_b) coupled by a known causal edge (e.g. V_mm -> V_blk under reclaim, V_irq -> V_sched under softirq raise, V_sock -> V_blk under fsync), let delta_ab(t) be the observed time gap between the dependent event in V_b and its precursor in V_a during the tick window. The lower bound delta_ab^min is a *kernel constant* (kernel-build dependent, measured at boot) representing the minimum number of context switches and memory barriers separating the two observation points. C_1^Einstein = 1 - (1/M) * sum_{(a,b) in coupled-pairs} 1[ delta_ab(t) < delta_ab^min ] A violation indicates either (i) a corrupted timestamp source (vDSO clock drift, hypervisor TSC issue) or (ii) a kernel anomaly where an event appears to precede its cause. Both are meaningful operational signals and depress C_1. C_1^tau (temporal stability). The Shannon entropy of the dominant-event-fingerprint distribution over the trailing K = 32 ticks per vantage. A stable kernel produces one dominant fingerprint per vantage (e.g. "user task on CPU 0", "NVMe IRQ on CPU 2"); under degradation the fingerprint distribution spreads, H_v rises, C_1^tau collapses. C_1 = min(C_1^Einstein, C_1^tau), as in v1.1. --------------------------------------------------------------------------- 3.2 C_2 -- informational coherence (sub-system JSD) --------------------------------------------------------------------------- Definition unchanged from v1.1 Sec. 2.2.a: C_2 = 1 - JSD_norm( {p_v} ), JSD_norm = JSD / log_2( min(N, |A|) ). Implementation. JSD between Count-Min sketches of disjoint subsystems would be undefined if the alphabets did not overlap. The kernel profile resolves this by mapping all per-vantage distributions onto a *common abstract alphabet*: A_kernel := { idle, light-load, contention, saturation, starvation, failure } with six bins. Each vantage's per-bucket Count-Min counts are collapsed into one of the six bins by a deployment-time mapping table (built at boot from the vantage's own observation distribution over its baseline period). JSD is then computed on these six-bin distributions across all N vantages. This is the same constructional move that the data-plane profile makes for L1 -> JSD_norm (lookup-table calibration). The kernel mapping is simpler because the alphabet is small (6 bins) and universal across subsystems. Interpretation. C_2 falls when one subsystem reports "saturation" while others still report "light-load" or "idle" -- the structural signature of a localised hotspot before it propagates across subsystems. C_2 collapses entirely when all vantages converge on "saturation" or "starvation" simultaneously -- the structural signature of a global kernel degradation event. --------------------------------------------------------------------------- 3.3 C_3 -- topological coherence (touched-object Jaccard) --------------------------------------------------------------------------- Definition unchanged from v1.1 Sec. 2.3: C_3 = (1 / C(N,2)) * sum_{i ALARM requires 3 consecutive WATCH ticks plus an upward D^2 trend; ALARM -> CRITICAL requires 5 consecutive ALARM ticks plus D^2 above the CRITICAL threshold for at least 2 of those ticks. Transition counters live in a BPF map (4 bytes per vantage). 4.3 Containment by design. Unlike the data-plane profile, where the consequence of a false positive is to drain an ECMP next-hop (degrading capacity but not correctness), the consequence of a false positive in the kernel profile is to throttle a userspace workload (degrading throughput visibly to that workload). Operationally, this demands: - a *per-workload allow-list* of which tunables MVPS-K is permitted to touch automatically; - a *no-action default* (WATCH-only) on any workload not on the list; - a *kill-switch* (/sys/kernel/debug/mvps/disable) that reverts all MVPS-applied tunables and freezes further action. These are operational hygiene, not framework requirements; the framework itself only emits Phi_K and the per-vantage D^2 decomposition. Whether anything happens as a consequence is a policy decision external to MVPS. ============================================================================== 5. Worked example: coordinated cross-subsystem degradation ============================================================================== Scenario summary (synthetic). Host : 32-core, 128 GiB, NVMe SSD, dual 25 GbE. Kernel : 6.x with MVPS-K eBPF programs loaded (5 vantages, Delta_t = 100 ms). Workload : a database container (cgroup A, latency-sensitive, p99 SLA 5 ms) co-located with an analytics container (cgroup B, throughput-greedy, no SLA). Baseline : (C_1, C_2, C_3) ~= (0.96, 0.92, 0.18); D^2 ~ 1.5; Phi_K = BAU. Failure onset (synthetic). At t = 0 cgroup B begins a large multi-stage analytics job that allocates ~80 GiB of anonymous memory, performs heavy mixed sequential and random I/O against the NVMe device, and saturates 8 CPUs with compute-bound threads. The kernel enters a regime where: - V_mm sees direct-reclaim latency rise from baseline 200 us to >3 ms; - V_blk sees per-device queue depth saturate at 256 and completion latency spread from 50 us-tail to 8 ms-tail; - V_sched sees runqueue length on the 8 cgroup-B CPUs grow to 6-12 runnable tasks each, while the cgroup-A CPUs remain at <2 (asymmetric saturation); - V_sock sees database TCP flows enter a CWND-collapse pattern -- not because of network loss, but because the socket-layer fsync path is back-pressured by V_blk; - V_irq sees NVMe completion-IRQ rate triple and spread to CPUs that did not service NVMe IRQs in baseline. What MVPS-K sees, tick by tick. t = 100 ms (1st tick). (C_1, C_2, C_3) = (0.85, 0.70, 0.32). D^2 = 4.1. Phi_K = BAU still (below WATCH threshold) but the per-vantage contribution attributes 60% of D^2 to V_mm. t = 300 ms (3rd tick). (C_1, C_2, C_3) = (0.70, 0.50, 0.45). D^2 = 8.6. Phi_K transitions BAU -> WATCH. The userspace daemon captures the bundle. Per-vantage attribution: V_mm 35%, V_blk 30%, V_sched 25%, V_sock 10%, V_irq trace. t = 700 ms (7th tick). (C_1, C_2, C_3) = (0.55, 0.32, 0.55). D^2 = 12.4. Phi_K transitions WATCH -> ALARM after hysteresis. By policy, the daemon applies io.weight reduction on cgroup B (from 100 to 50) and signals the orchestrator that cgroup A's SLA is at risk. t ~ 1.5 s (15th tick). Database p99 has briefly touched 6 ms but did not break the 5 ms SLA *on a sustained window*. After the io.weight throttle, V_blk completion latency tail recovers; C_3 falls toward baseline; D^2 falls below WATCH within ~10 additional ticks; Phi_K -> BAU. What this would look like without MVPS-K. Today on the same workload, the operator's signals are: - vmstat shows si/so rising, but only every second; - iostat shows %util at 100% with rising await, but no attribution to cause; - top shows cgroup B threads dominating CPU, but no insight into whether that is causing cgroup A's slowdown; - the database log shows p99 latency rising; the orchestrator does not see this until a future polling window. The operator typically identifies the noisy-neighbour interaction within tens of seconds to minutes of receiving customer alerts. MVPS-K compresses that interval to ~700 ms detection and ~1 s mitigation, with attribution per vantage. Caveat. This example is synthetic. The numerics for D^2 trajectory and SLA outcome are constructed from software simulation grounded in published kernel-subsystem latency distributions (Linux Plumbers Conference workloads, Brendan Gregg's analyses of similar interference patterns) but do not constitute a measurement on a real instrumented kernel. Quantitative validation is open work item K9.1. ============================================================================== 6. Implementation budget on Linux ============================================================================== 6.1 In-kernel storage (BPF maps). Per-vantage state: Count-Min sketch (4 x 256 x 2 B) = 2.0 KiB Bloom filter S_i (4096 bits) = 0.5 KiB Latency estimator + counters = 64 B Hysteresis counter = 4 B ------- ~2.6 KiB N = 5 vantages: ~13 KiB Sigma^{-1} (3x3, recalibrated from userspace) = 36 B Lookup tables for entropy proxy + exp = 2 KiB ------- Total per host ~15 KiB This is two orders of magnitude smaller than typical bpftrace working sets on a production host. The cost is dominated by perf-ring buffers (~1-4 MiB per CPU), which are *not* MVPS- specific and would be required by any other eBPF observability tool on the same host. 6.2 Per-tick CPU cost. At 10 Hz tick (Delta_t = 100 ms): eBPF programs on hot tracepoints (sched_switch, mm_page_alloc, block_rq_*, tcp_retransmit_skb) ~0.2 us per event Userspace tick close-out (drain rings, sketch merge, distribution mapping, JSD/Jaccard, Mahalanobis) ~150 us per tick Sigma^{-1} recalibration (every 30 s, 300 ticks) ~80 us amortised -------------- Steady-state CPU cost on a 32-core host <0.05 % of one CPU At higher tick rates (1 kHz, Delta_t = 1 ms) the CPU cost rises to ~5 % of one CPU, which is acceptable for diagnostic / troubleshooting profiles but not for always-on deployment. 6.3 Where the budget breaks. On hosts that are *themselves* under severe resource contention (which is precisely when MVPS-K is most useful), the userspace drain may be itself starved. The recommended profile uses a dedicated cgroup with reserved CPU and memory for the MVPS-K daemon. The size of that reservation is 1 CPU and 256 MiB; this is small but non-zero, and is an operational cost of the framework that must be budgeted explicitly. ============================================================================== 7. Kernel telemetry export ============================================================================== 7.1 Local exposure. The MVPS-K daemon exports per-tick (C_1, C_2, C_3, H, Phi_D, Phi_K) plus per-vantage D^2 contribution as a JSON document at: /sys/kernel/debug/mvps-k/state.json (debugfs) /run/mvps-k/state.json (tmpfs, world-readable) 7.2 Cross-host correlation. The daemon optionally exports to a Prometheus endpoint with metric names: mvps_k_c1{host,vantage} mvps_k_c2{host,vantage} mvps_k_c3{host,vantage} mvps_k_phi_d{host} mvps_k_phi_k{host} Scraped at the tick rate (10 Hz default) into a TSDB; standard Grafana dashboards then provide cross-host coherence overviews. When the host also runs the data-plane profile, the two phase labels (Phi_K_kernel and Phi_K_dataplane) can be jointly evaluated -- this is the *cross-layer* coherence signal that the unification document (MVPS_UNIFIED_STATE_SPACE.txt) formalises. 7.3 No in-band wire telemetry. Unlike the data-plane profile, the kernel profile does *not* emit MVPS state into the wire format of egress packets. There is no kernel analogue to the IOAM TLV in this profile; kernel state stays on the host. The cross-host story is exclusively pull-based via Prometheus or similar. ============================================================================== 8. Formal mapping back to v1.1 (and forward to the unification) ============================================================================== 8.1 Substitution of vantage type. v1.1's vantage type V is the external probe (math companion Sec. 1). The data-plane profile substitutes the vantage type with V_dp (Count-Min sketch + Bloom filter + RTT register + counters on a forwarding object). This profile substitutes with V_k: V_k := ( CMS_subsystem x Bloom_objects x LatencyEstimator x Counters x HysteresisState ) The bundle type becomes B_k = (V_k)^N. The functional signatures of the coherence axes are unchanged: C_1', C_2', C_3' : (V_k)^N -> [0, 1] with the constructions of Sec. 3 above. As in the data-plane profile, the constructions agree with v1.1's verbatim constructions up to fixed-precision quantisation, sketch approximation, and (in the kernel profile specifically) the universal-alphabet mapping for JSD. 8.2 What this profile alone establishes. The kernel profile, if implemented, would establish empirically that v1.1's algebra applies to a vantage type *radically different from packet-network probes*: vantages here observe software constructs (kernel data structures, locks, queues), not physical paths. If C_1, C_2, C_3 behave under controlled cross-subsystem perturbations the way v1.1 predicts they should -- collapsing under coordinated stress, recovering under relief, yielding sensible Sigma^{-1} baselines -- the result is a second independent corroboration of the framework's invariance claim. Combined with the data-plane profile (silicon-substrate vantages) and the observatory profile (external-prober vantages), the kernel profile completes a *three-surface witness* spanning physical paths, forwarding silicon, and operating-system state. Three witnesses on three radically different substrates is the empirical core of the unification argument made formally in MVPS_UNIFIED_STATE_SPACE.txt. 8.3 What this profile alone does not establish. This profile does not, on its own: - prove the unification claim (the three-surface result is necessary but not sufficient; see U9 in the unification document); - validate the framework against real cross-subsystem incidents (open work K9.1); - characterise the false-alarm rate under the universal- alphabet mapping (open work K9.3); - establish hardware-portability of the eBPF programs across non-Linux kernels (open work K9.5). It does, however, provide the most testable surface on which the unification claim can be falsified quickly, given mature tooling (eBPF, bpftrace, perf) and a large body of published kernel- subsystem latency distributions for grounding the synthetic calibration. ============================================================================== 9. Open questions and validation roadmap (K9.x) ============================================================================== K9.1 Reference eBPF implementation. Status : not started. Scope : libbpf-based daemon plus five eBPF programs (one per vantage), targeting Linux 6.x. Shipped with a deterministic synthetic-load harness (stress-ng + fio + iperf3 recipes) that reproduces the Section 5 example. Risk : low technically; eBPF idioms are standard. K9.2 Universal-alphabet mapping calibration. Status : conceptual. Scope : determine, per workload class, the mapping table that collapses per-vantage CMS sketches into the 6-bin universal alphabet (Sec. 3.2). Characterise sensitivity of C_2 to mis-calibration. Risk : moderate. This is the kernel-profile-specific analogue of D9.3 in the data-plane profile. K9.3 False-alarm rate on production kernels. Status : not started. Scope : 1 month of MVPS-K WATCH/ALARM events on at least three production hosts (database, web, batch), manually labelled by the host operator. Compute precision/recall against ground-truth incidents. Risk : access-bound, not technical. K9.4 Cross-layer coherence (Phi_K_kernel x Phi_K_dataplane). Status : not started. Scope : when the host runs both this profile and the data-plane profile, characterise the joint distribution of Phi_K_kernel and Phi_K_dataplane during synthetic and real incidents. This is the most direct empirical input to the unification claim. Risk : low; the data is straightforward to collect once K9.1 is done. K9.5 Portability across kernels. Status : conceptual. Scope : a kernel-agnostic vantage definition (sched / irq / mm / blk / sock) that admits implementations on FreeBSD (DTrace), illumos (DTrace), and Windows (ETW + DTrace4Windows). The framework axioms are OS-independent; this open item is about the instrumentation translation table. Risk : moderate. DTrace and ETW expose comparable signals but at different granularities; the universal- alphabet mapping (K9.2) may need per-OS variants. K9.6 Hardware-counter vantages. Status : conceptual. Scope : add per-CPU PMU counters (LLC misses, branch mispredictions, memory-bandwidth saturation, dTLB walks) as additional vantage types V_pmu. This pushes the framework one layer deeper, from kernel software constructs to microarchitectural events. Conjecture (untested): the same C_1, C_2, C_3 algebra continues to apply. Risk : moderate. PMU counters are per-CPU, per-vendor idiosyncratic; PMU virtualisation is incomplete in many hypervisors. K9.7 Companion I-D draft. Status : this document is the seed. Scope : align with IETF OPSAWG style; submit as draft-melegassi-opsawg-mvps-kernel-00. Risk : low. ============================================================================== 10. References ============================================================================== Normative. [MVPS-MATH] Melegassi, L. "MVPS -- Three-Layer Mathematical Structure". Catellix Research, v1.1, 2026-05-20. [MVPS-DP] Melegassi, L. "MVPS -- Data-Plane Profile (Proposal)". Catellix Research, v0.1, 2026-05-21. [MVPS-UNI] Melegassi, L. "MVPS -- Unified State Space (Proposal)". Catellix Research, v0.1, 2026-05-21. Informative. [BOVET] Bovet, D. and Cesati, M. "Understanding the Linux Kernel", 3rd ed. O'Reilly, 2005. [LOVE] Love, R. "Linux Kernel Development", 3rd ed. Addison-Wesley, 2010. [GREGG2019] Gregg, B. "BPF Performance Tools: Linux System and Application Observability". Addison-Wesley, 2019. [PSI] Weiner, J. et al. "PSI -- Pressure Stall Information". Linux kernel documentation, 2018. https://www.kernel.org/doc/html/latest/ accounting/psi.html [SCHED-EXT] Heo, T. et al. "sched_ext: Extensible Kernel Scheduling Class". LWN 945966, 2023. [BPFTRACE] Gregg, B. et al. "bpftrace: High-Level Tracing Language for Linux Systems". https://github.com/bpftrace/bpftrace [POINCARE] Poincare, H. "Science et Methode". Flammarion, Paris, 1908. ============================================================================== Document history ============================================================================== v0.1 2026-05-21 Initial draft. Third profile in the MVPS series (after observatory / v1.1 and data-plane / v0.1). Status: proposal, not implemented as eBPF on a running kernel. Authors: L. Melegassi (Catellix Research). ============================================================================== End of document ==============================================================================