{"id":"f554ff1f-b527-462a-b147-1622bad67424","arxiv_id":"2509.09879","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":3,"one_line_summary":"eHashPipe applies the HashPipe sketch inside eBPF to monitor top-k CPU and memory processes per PID, claiming high accuracy and up to 14x finer temporal resolution than top.","lead":"This paper builds eHashPipe, a Linux kernel tool using eBPF and a sketching algorithm to track the top CPU- and memory-consuming processes in near real time. It claims higher accuracy and finer temporal resolution than the standard top command while adding little overhead.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Algorithm 1 feeds negative deallocation values through HashPipe's forced-eviction logic, allowing a free event to evict a positive heavy-hitter and corrupt the Top-k memory result. The top-based ground truth cannot detect this because it is the tool eHashPipe claims to replace.","rationale":"The reader's circular-ground-truth objection is real, but the deeper problem is algorithmic: HashPipe's eviction rules presume nonnegative counts, and Algorithm 1 violates that by inserting negative deallocation values at stage 0. This means the memory Top-k claim is suspect even before benchmarking. The abstract/Table 1 mismatch is a further red flag. My read therefore confirms the reader's REJECT verdict rather than altering it; the strongest immediate step is to release artifacts and run the controlled churn test above.","tokens_in":7159,"tokens_out":7608,"duration_ms":87550,"concrete_test":"Using a userspace simulator of Algorithm 1 (or the actual eBPF module), feed a deterministic trace: process A allocates 100 units once; process B allocates 1 unit and frees it repeatedly; choose PIDs/hash seeds so both map to the same stage-0 slot. After each free, compare the sketch's Top-1 memory output with the exact sorted counts. Run 10,000 iterations and vary collision patterns. If a negative free ever displaces A from stage 0 and A is not fully recovered downstream, the memory Top-k pipeline is unsound; this would require recomputing the Table 1 memory-precision rows under realistic allocator churn.","verdict_should_be":"UNCHANGED","load_bearing_attack":"HashPipe is designed for monotonic additive counts; eHashPipe's memory pipeline instead feeds negative updates for free/munmap (Section II-A.3) into the same always-kick pipeline. In Stage 0, when the hashed slot is occupied by a different PID, `swap(entry, S0[h0])` replaces the occupant with the new event regardless of value (Algorithm 1). A deallocation with negative size can therefore evict a large positive counter and leave a negative entry in stage 0; the displaced positive entry is pushed downstream and may be dropped on later collisions. Because the per-stage hash is on PID, a later free from a process whose entry lives in a different stage can trigger exactly this blind eviction. Negative counters accumulate and can occupy slots that should hold heavy hitters. The evaluation cannot catch this: ground truth is constructed from top snapshots (Section IV-C), which is the interval-based /proc polling tool eHashPipe claims to outperform, and the abstract's '100% at k=10' conflicts with Table 1's 90.0% memory accuracy. No experiment isolates high allocation/deallocation churn, so the central memory-accuracy claim is unsubstantiated.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes eHashPipe, an eBPF-based system that adapts the HashPipe sketch algorithm to track top-k CPU and memory-consuming processes in the Linux kernel, alongside exact tracking for user-specified PIDs. It describes two in-kernel pipelines: one for memory events (allocations and deallocations) and one for on-CPU time derived from sched_switch tracepoints. The evaluation claims high top-k accuracy relative to top, roughly 14x finer temporal resolution, and low overhead. The authors argue this provides lightweight, responsive observability suitable for cloud and edge environments.","tokens_in":7505,"tokens_out":5865,"duration_ms":65909,"significance":"If the results held, eHashPipe would be a practically useful contribution to kernel-level observability, combining the compact HashPipe sketch with eBPF for top-k resource monitoring. The implementation includes useful engineering details, such as physically unrolled loops to satisfy eBPF verifier constraints, configurable pipeline depth/slots, and atomic updates to handle race conditions. However, the current evidence is not sufficient: the headline accuracy claim is internally inconsistent, the ground truth is derived from the very tool the paper claims to supersede, no error bars or repeated trials are reported, and the memory pipeline's handling of negative deallocation events raises a correctness concern. The idea remains potentially viable, but the empirical and algorithmic basis needs substantial rework.","major_comments":[{"comment":"The abstract states '100 percent Top-k precision for CPU and memory at k = 1, 5, and 10,' but Table 1 reports Memory Accuracy of only 90.0% at k=10. This is a direct internal contradiction in the paper's headline result. The abstract must be corrected and the experiment repeated to determine which number is actually supported.","section":"Abstract; Table 1"},{"comment":"Ground truth is constructed from snapshots of the top command, which aggregates /proc values. This is not an independent baseline: top is the tool eHashPipe claims to outperform, and its interval-based sampling and smoothing can misrank or miss short-lived processes. No repeated trials or error bars are reported for Table 1, so the accuracy numbers cannot be considered statistically reliable.","section":"§IV-C"},{"comment":"Deallocation events are fed into the pipeline as entries with negative size. In Stage 0, the always-kick rule swaps the new entry into the slot regardless of value, so a negative deallocation can evict a large positive heavy-hitter and corrupt the memory top-k result. The evaluation does not include a workload with high allocation/deallocation churn, so this issue is not exposed. The deallocation path should be revised (e.g., only updating matching entries or bypassing stage 0 for negative entries) and a churn-focused experiment added.","section":"Algorithm 1; §II-A.3"},{"comment":"The claimed 'about 14x finer temporal resolution' is not substantiated. No measurement methodology, raw trace data, or statistical support is given. Moreover, §IV-D says detection frequency is configured once every 2 seconds to align with top, while §IV-E describes a 0.01-second target sampling interval. These contradictory statements need to be reconciled and the resolution claim demonstrated with concrete measurements.","section":"§IV-E"},{"comment":"The CPU overhead of 'about 20%' is reported without a baseline or methodology. 20% is not obviously 'very low' and needs context, such as comparison against top or an unmonitored baseline, and a description of how the overhead was measured.","section":"§IV-F"}],"minor_comments":[{"comment":"Inconsistent capitalization: eHashPipe in some places, eHashpipe in others. The abstract also contains 'T op-k' formatting errors. Please unify.","section":"Throughout"},{"comment":"The text mentions monitoring '12 key allocation functions' but does not list them. Provide the actual probe list.","section":"§II-A.1"},{"comment":"Figure captions are generic ('Fig. 1: Always Kick Out'); the figures need axes, units, and clear descriptions. The text should reference specific aspects of each figure.","section":"Figures 1-6"},{"comment":"There is a typo: '/proc sfile' should be '/proc filesystem'. Also specify the exact top command, interval, and delay used for ground truth construction.","section":"§IV-C"}],"recommendation":"major_revision","confidential_remarks":"The reader's harsh take has merit: the current version has an internal contradiction in the headline accuracy claim and the evaluation is not independent. However, the identified problems are addressable: the memory pipeline can be fixed to handle negative updates safely, and the evaluation can be redone with an independent ground truth and proper statistical reporting. I therefore see this as a major revision rather than a categorical rejection, but the next version must resolve these issues before it can be considered for publication."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nQuick take: this is a legitimate systems-engineering paper, not a research breakthrough. The new thing is applying HashPipe, a network heavy-hitter sketch, to per-PID CPU and memory telemetry inside eBPF. That is a sensible extension, and the in-kernel design with unrolled loops and atomic updates shows real implementation care. The per-PID exact tracking via a dedicated BPF map is plain and correct. I believe the CPU pipeline, being monotonic, is sound. The memory pipeline is where the trouble starts.\n\nThe abstract claims 100% memory accuracy at k=10, but Table 1 reports 90.0%. That is an internal contradiction in the central result, and it is not a typo you can ignore — the abstract and table are the two places a reader checks first. The stress-test note about negative deallocations in the always-kick pipeline deserves attention too. HashPipe assumes monotonic additive counts; feeding negative values into a forced-eviction stage can evict a positive heavy hitter on a free event. Algorithm 1 in the paper does exactly this, and no experiment isolates high allocation/deallocation churn. The paper does mention atomic operations for data consistency, but that is a race fix, not a fix for the eviction semantics.\n\nThe bigger structural problem is the ground truth. They validate against top, which they describe as coarse and smoothed and claim to outperform. Top's snapshot-based ranking is not an independent measure of the true top-k set, so the accuracy numbers are self-referential. There are also no error bars or repeated trials. These issues are load-bearing because the paper's main quantitative claims rest on them.\n\nWhat the paper does well: the responsiveness argument is plausible and deserves credit. Showing that top's effective resolution saturates around 0.15s while eHashPipe gets ~0.011s is a meaningful observation for the cloud/edge monitoring audience. The overhead numbers (1.2 MB memory module, ~20% CPU measured with perf) are useful, though the CPU overhead number is surprisingly high and needs more explanation.\n\nBottom line: the engineering is real, the evaluation is not. I would not reject on novelty — applying HashPipe to process telemetry is a reasonable incremental step. But the central accuracy claim is unsubstantiated as written. A serious referee could fix this paper if the authors redo the ground truth with an independent mechanism (e.g., /proc/pid/statm aggregated directly at high frequency, or a kernel-side tracepoint counter) and address the negative-eviction semantics.\n\nFor peer review: yes, it deserves referee time — the idea is worth examining and the flaws are repairable. But I would not cite it until the evaluation is redone. Reading group: maybe, as a case study in why evaluation baselines matter.\n\nRecommendation: send to peer review, with a strong expectation of major revision.","headline":"A reasonable engineering idea — HashPipe in eBPF for per-PID CPU/memory top-k — undermined by a contradictory accuracy claim and a ground-truth built on the very tool it claims to beat.","tokens_in":7933,"tokens_out":708,"would_cite":false,"duration_ms":10004,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"eHashPipe moves a network sketch into the kernel via eBPF and uses it to name the top CPU and memory consumers faster and more precisely than top.","keywords":["eBPF","top-k monitoring","HashPipe sketch","CPU utilization tracking","memory profiling","kernel observability","per-process monitoring","real-time telemetry"],"falsifier":"Run a workload with a known mix of short-lived and long-lived processes, and compare eHashPipe's top-k list against deltas of /proc/<pid>/stat utime+stime (or cgroup v2 cpu.stat) sampled at 1 ms; if the overlap falls materially below the paper's reported 83–100% for k ≤ 30, or if eHashPipe misses bursts that the /proc deltas show, the central claim is refuted. Equivalently, construct a synthetic allocation workload whose true top-k is known from the allocation sizes, and check the sketch's output directly.","tokens_in":7124,"feed_emoji":"⚡","tokens_out":5789,"duration_ms":61089,"temperature":0.7,"pith_summary":"eHashPipe claims that a sketch algorithm for network heavy hitters can move into the Linux kernel via eBPF and track which processes consume the most CPU and memory in real time. The paper implements two in-kernel pipelines, one fed by allocation/deallocation probes and one by the scheduler's context-switch tracepoint, and reports top-k precision of 100% at k = 1, 5, and 10 and 83–95% at k = 20–30 when compared against top-derived ground truth. The system also tracks user-specified PIDs exactly in separate BPF maps, avoiding sketch evictions for critical processes. Its claimed advantage is responsiveness: updates every ~0.01 s, roughly 14 times finer than top's effective sampling resolution, at a memory cost of about 1.4 MB total and moderate CPU overhead. This matters because existing eBPF monitors summarize single resources but do not prioritize across processes, and userspace tools smooth away bursts that matter for diagnosing training or cloud workloads.","feed_headline":"In-kernel sketch catches top CPU and memory hogs top misses","feed_subtitle":"HashPipe-style counters in the kernel hit near-perfect top-k precision and capture bursts top flattens.","key_machinery":"The carrying object is the HashPipe sketch: d stages, each with a hash table of fixed-size slots holding (PID, usage count); a memory event starts at stage 0, where the slot is forced to accept the new entry and the displaced entry moves to stage 1, which swaps only if the newcomer's count exceeds the resident's. The same cascade runs for CPU deltas, which are captured by timestamping sched_switch events per thread and attributing each on-CPU interval to the owning PID. eBPF probes on 12 allocation functions plus free/munmap feed the memory pipeline; the always-kick-out rule guarantees every process enters the structure, while later-stage comparison keeps the heaviest PIDs in the chain. Dedi","core_discovery":"The paper advances the claim that HashPipe, a multi-stage sketch that keeps a small table of counters per stage and evicts the smallest entry on collision, works for process-level resource streams as well as network flow streams. Each memory event or scheduling delta is hashed into a pipeline; stage 0 always kicks out the incumbent, later stages replace only when the incoming count is larger, and the evicted entry cascades down. The result is a compact approximate top-k structure updated in constant time per event. The paper pairs this with per-PID lossless maps so a chosen process is never evicted. The evaluation claims 95–100% overlap with top's top-k set for k ≤ 20 on CPU, 90–100% on memo","pith_inferences":["The reported accuracy is measured against top-derived snapshots, which sample /proc on a fixed interval; a more direct comparison using per-process accounting from /proc/<pid>/stat or cgroup cpu.stat could change the precision numbers, especially for short-lived processes that top's interval may alias.","The 14x temporal-resolution claim compares reporting intervals rather than event-detection latency; a controlled experiment that injects a known CPU burst and measures time-to-detection would isolate the system's true reactivity.","HashPipe's accuracy depends on the skewness of the resource distribution; workloads where many processes have similar usage are the natural stress test, since the compare-and-swap rule favors heavy hitters and may lose middle-of-pack processes.","The same instrumentation could be pointed at GPU kernel events or network softIRQ events, as the paper's own future work suggests, turning eHashPipe into a multi-resource observability plane rather than a CPU/memory monitor."],"forward_implications":["Top-k monitoring can run in the kernel at ~0.01 s reporting rates, making transient CPU and memory bursts visible to schedulers, orchestrators, and operators without userspace polling.","Per-PID exact tracking can coexist with approximate global top-k, so critical workloads are never approximated away by eviction.","The same sketch pipeline can be extended to other additive or monotonic system counters, such as I/O bytes or network packets, as the paper's modular design already separates pipeline logic from event source.","The measured footprint (~1.2 MB for memory tracking, ~183 KB for CPU tracking) makes the approach viable on resource-constrained cloud and edge nodes."],"fun_headline_variants":["Kernel sketch catches top hogs at 100% precision for k up to 10","eHashPipe: 14x finer burst detection than top with low overhead","In-kernel HashPipe achieves near-perfect top-k and per-PID tracking","Near-perfect top-k for CPU and memory from an eBPF sketch"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The accuracy claims rest on ground truth collected from the top command's interval-based snapshots; if top misranks or misses short-lived processes, the comparison does not measure true top-k fidelity.","fun_headline_variants_meta":{"raw":{"variants":["Kernel sketch catches top hogs at 100% precision for k up to 10","eHashPipe: 14x finer burst detection than top with low overhead","In-kernel HashPipe achieves near-perfect top-k and per-PID tracking","Near-perfect top-k for CPU and memory from an eBPF sketch"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000266,"raw_usage":{"total_tokens":1451,"prompt_tokens":753,"completion_tokens":698,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":497,"completion_tokens_details":{"reasoning_tokens":620}},"tokens_in":497,"tokens_out":698,"duration_ms":8168,"temperature":1.0,"reasoning_tokens":620,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T18:30:35.903040+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a workload with a known mix of short-lived and long-lived processes, and compare eHashPipe's top-k list against deltas of /proc/<pid>/stat utime+stime (or cgroup v2 cpu.stat) sampled at 1 ms; if the overlap falls materially below the paper's reported 83–100% for k ≤ 30, or if eHashPipe misses bursts that the /proc deltas show, the central claim is refuted. Equivalently, construct a synthetic allocation workload whose true top-k is known from the allocation sizes, and check the sketch's output directly.","supporting_citations":[],"review_version":1}