{"id":"f006de9f-36ba-4206-a488-31d9ee2667a5","arxiv_id":"2506.23672","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"A DVFS-aware, linear power model built from automatically selected hardware counters plus an in-kernel Linux monitor (Runmeter) estimates CPU and GPU power with 7.5% average error on a restricted frequency range.","lead":"This paper builds a power-estimation model for a heterogeneous CPU+GPU chip by correlating hardware performance counters with measured power, then runs it inside the Linux kernel with an open-source framework. The result is a low-overhead way to monitor power in real time, which could support power-aware scheduling on embedded systems.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The headline 7.5% MAPE and 0.7% overhead apply only to a filtered frequency regime and a CPU-only kernel deployment; the full-system online claim is not demonstrated.","rationale":"I read the paper as a solid systems contribution: the methodology is clearly specified, the limitations are disclosed rather than hidden, and the Runmeter framework is open source. The reader's conditional verdict is appropriate, and my stress-test does not move it. I partially agree with the reader's identified weakest assumption: the independence assumption is indeed load-bearing and the paper's own data show its failure mode in Section 5.3. My additional concern is that the online overhead claim is scoped to the CPU-only monitor, so the full-system online deployment described in the abstract remains unverified. Both concerns share the same remedy: report accuracy and overhead for the complete model over the full DVFS space, or explicitly scope the headline claims. No ad hominem is intended; the issue is the gap between the abstract's general claim and the conditional evaluation.","tokens_in":16908,"tokens_out":4321,"duration_ms":47906,"concrete_test":"Deploy the full combined LUT (CPU model plus the eight GPU PMCs per frequency) inside Runmeter and run the same validation workloads at fCPU = 2.3 GHz with fGPU in {115, 300, 600} MHz. If the instantaneous power MAPE exceeds 10% or the kernel callback overhead exceeds 0.7% in this configuration, the headline accuracy and overhead numbers must be restated as applying only to the filtered regime and to CPU-only monitoring.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim of 7.5% MAPE and 1.3% energy error rests on the subsystem-independence assumption in Eq. (2). Section 5.3 shows this assumption fails when fGPU is much lower than fCPU: the combined model's average MAPE over all CPU/GPU frequency combinations is 8.6%, and the 7.5% figure is obtained only after excluding fGPU <= 600 MHz. The paper's justification that such divergent-frequency operation is 'highly unlikely' is an assertion, not a measured workload distribution, so the headline accuracy is conditional on an untested operating-region assumption. Separately, the 0.7% worst-case overhead in Section 5.4.3 is measured only for the CPU-only in-kernel model at 10 Hz; the complete CPU+GPU model with eight GPU PMCs is never executed inside Runmeter. Thus the abstract's claim of an online 'complete model' with low overhead is not supported by the evaluation, even though the CPU monitor itself is carefully validated.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents a data-driven methodology for PMC-based power modeling of heterogeneous embedded platforms, decomposing the system into per-subsystem linear models stored in a DVFS-aware lookup table and trained via non-negative least squares. The authors also introduce Runmeter, an open-source Linux kernel module for PMC sampling and online model evaluation. On an NVIDIA Jetson AGX Xavier, the combined CPU+GPU model is reported to achieve an average instantaneous power MAPE of 7.5% and an energy error of 1.3%, with Runmeter adding a worst-case overhead of 0.7%.","tokens_in":17137,"tokens_out":3135,"duration_ms":34614,"significance":"If the claims hold, the paper would make a useful contribution: an automated, architecture-agnostic, decomposable, and low-overhead alternative to hand-tuned analytical power models, with public code and kernel integration. The NNLS-based training, PMU-aware counter selection, and fixed-point in-kernel implementation are well-motivated. The CPU monitor is carefully validated, and the overhead measurements are useful. However, the headline accuracy and overhead figures are only demonstrated under restricted conditions, and the validation methodology is not sufficient to support the stated generalization.","major_comments":[{"comment":"The headline numbers 7.5% MAPE and 1.3% energy error are reported only for the restricted frequency range fGPU > 600 MHz; over all CPU/GPU frequency combinations the model's average MAPE is 8.6% and the energy error is 2.5%. The justification that divergent-frequency operation is 'highly unlikely' is an assertion, not a measurement of actual workload frequency residency. As the abstract presents the 7.5%/1.3% figures as the overall result, the central accuracy claim is conditional on an untested operating-region assumption and must be rephrased or supported by workload-distribution data.","section":"§5.3, Abstract"},{"comment":"The validation uses a random 70/30 split of the same benchmark workloads used for training, and the number of PMCs (e.g., eight for the GPU) and the p-value threshold are tuned using the validation set. This procedure does not demonstrate generalization to unseen workload behavior, and the reported errors are likely optimistic. A held-out workload set, leave-one-workload-out cross-validation, or an independent benchmark suite is needed to support the claim of a 'dataset-independent result' made in §3.2.","section":"§5.2.2, §5.3"},{"comment":"The 0.7% worst-case overhead is measured only for the in-kernel CPU power model. The complete CPU+GPU model, which tracks eight GPU PMCs per frequency and reconfigures the tracked counter set on DVFS changes, is never executed inside Runmeter. Therefore the abstract's claim that Runmeter provides low-overhead online execution of the complete model is not supported by the evaluation; the overhead of the full subsystem set, including GPU counter sampling and LUT reconfiguration, remains undemonstrated.","section":"§4, §5.4.3"},{"comment":"The linear composition in Eq. (2) rests on the assumption of power independence among subsystems, which the paper itself shows to fail in §5.3 for low fGPU relative to fCPU, where CPU stall behavior is not captured. The paper's response—excluding such cases—makes the model's validity domain a design choice rather than a consequence of the modeled physics. A concrete test, such as profiling the frequency residency of representative real workloads and reporting the error distribution with and without the filter, would make the restriction transparent and the accuracy claim meaningful.","section":"§3.4, Eq. (2)"}],"minor_comments":[{"comment":"The y-axis label reads 'Power [mW]', but the plotted values (e.g., 10–15 in the bottom panel) are implausible for milliwatts and are presumably watts; please correct the unit.","section":"Figure 5"},{"comment":"The use of '✓✓✓' and '≈≈≈' symbols is not standard and is difficult to decode; provide a legend or use conventional check/cross marks.","section":"Table 1"},{"comment":"The sentence reporting 'MAPE between 3% and 4.4% ... with a standard deviation of approximately 5%' is ambiguous: the standard deviation likely refers to the per-workload MAPE spread, but it should be stated explicitly.","section":"§5.2.2"},{"comment":"The online CPU energy MAPE is about 9%, notably higher than the offline CPU MAPE of 3–4.4%; this discrepancy is attributed to transients in the text, but it deserves a brief quantitative discussion, for example the fraction of samples in transient phases.","section":"§5.4.2"},{"comment":"The underbrace in Eq. (4) appears malformed or, at least, the derivation of the simplified summation is not clearly stated; please rewrite for readability.","section":"Eq. (4)"},{"comment":"The paper extends prior work [12] but does not explicitly list the concrete differences in methodology or evaluation; a short paragraph in the introduction enumerating what is new relative to [12] would help readers place the contribution.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The paper is within the journal's scope and the underlying methodology has merit, but the abstract and introduction substantially overstate the demonstrated results: the accuracy figures are for a filtered frequency regime, and the overhead figure covers only the CPU-only model. The validation methodology also needs strengthening before the generalization claim is credible. I would advise the editor to request a revision that reports the full operating-region numbers prominently, adds a held-out workload evaluation, and either extends the Runmeter evaluation to the complete model or clearly qualifies the overhead claim."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper is a credible engineering extension of the authors' own prior work, and the Runmeter in-kernel monitoring framework is the genuinely new piece. The DVFS-aware LUT composition for CPU and GPU, the automated PMC selection that respects PMU constraints, and the fixed-point in-kernel implementation are all done carefully. I believe the modeling methodology itself is not revolutionary, but the complete package is useful for anyone doing power-aware scheduling or DVFS control on heterogeneous embedded platforms.\n\nThe evaluation is mostly honest about its own limits. The authors explicitly report the full-model MAPE of 8.6% and acknowledge that the subsystem-independence assumption fails when CPU and GPU frequencies diverge severely. They then exclude fGPU <= 600 MHz to get the headline 7.5% MAPE and 1.3% energy error, justifying this by saying such configurations are 'highly unlikely' because they are inefficient. That is an assertion, not a measured workload distribution, and it makes the headline number conditional on an untested operating-region assumption. The paper would be stronger if it reported the error as a function of the frequency ratio, or if it provided real workload traces showing how often divergent frequencies actually occur.\n\nThe other soft spot is the overhead claim. The 0.7% worst-case overhead is measured only for the CPU-only in-kernel model at 10 Hz. The complete CPU+GPU model with eight GPU PMCs is never executed inside Runmeter, so the abstract's implication that the full online model runs with that overhead is not supported. This is a real gap, but it is not fatal; the CPU monitor itself is well validated, and the GPU model could plausibly be integrated, but that integration is not demonstrated.\n\nOn validation methodology: the random 70/30 split from the same benchmark set leaves some risk of in-distribution optimism, and the PMC count appears to be tuned on the validation set. The paper would benefit from a held-out workload or a leave-one-benchmark-out cross-check. This is a standard weakness in this literature, and not a reason to reject, but worth noting.\n\nThe citation pattern looks fine, and the comparison to prior work is fair. The code and data appear to be open-sourced, which helps reproducibility.\n\nWho should read this? Anyone working on runtime power estimation, DVFS governors, or energy-aware real-time scheduling in embedded systems. It deserves a serious peer review, with requests to clarify the operating region for the headline numbers, to run the full model in Runmeter or explicitly state it is not yet implemented, and to tighten validation with a held-out workload set.","headline":"A solid, well-engineered power-modeling paper with a real kernel contribution, but the headline accuracy and overhead numbers are narrower than the abstract suggests.","tokens_in":17661,"tokens_out":1808,"would_cite":true,"duration_ms":21211,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims that an automated, DVFS-aware lookup-table power model built from hardware performance counters estimates instantaneous power to an average 7.5% error and energy to 1.3% error on the NVIDIA Jetson AGX Xavier, with online…","keywords":["power modeling","performance monitoring counters","DVFS","runtime power estimation","Linux kernel","heterogeneous embedded systems","lookup table model","NVIDIA Jetson AGX Xavier"],"falsifier":"Run a workload at an extreme frequency mismatch on the same board, such as CPU at 2.3 GHz with GPU at 115 MHz, and compare the model's online estimate against the onboard sensor over repeated trials; if the average error is substantially larger than 7.5% while CPU/GPU frequencies are held constant, the independence assumption is the limiting factor.","tokens_in":16731,"feed_emoji":"⚡","tokens_out":7057,"duration_ms":74870,"temperature":0.7,"pith_summary":"The paper claims that accurate, low-overhead online power measurement for heterogeneous embedded systems can be built from hardware performance counters alone, without microarchitectural knowledge. Its method profiles each sub-system's counters, keeps those most linearly correlated with measured power at each DVFS state, and trains a separate simple linear model for each state. These per-subsystem models are combined into a lookup table so that total power is the sum of a CPU term and a GPU term. On the NVIDIA Jetson AGX Xavier, the combined model reports an average instantaneous power error of 7.5% and an energy error of 1.3%, with those numbers holding for realistic CPU/GPU frequency combinations; across all tested combinations the average power error is 8.6%. The authors also present Runmeter, an in-kernel counter-sampling framework that evaluates the model online with a worst-case overhead of 0.7%, which would make power-aware DVFS and scheduling practical in the OS.","feed_headline":"Hardware counters estimate device power to 7.5% error","feed_subtitle":"A lookup-table model plus a Linux kernel monitor makes online power tracking cheap and responsive on heterogeneous chips.","key_machinery":"The load-bearing mechanism is the lookup table $\\mathrm{LUT}[d, f_d]$ holding one linear model per sub-system $d$ and DVFS state $f_d$. The characterization pipeline normalizes PMC counts by the sampling period, runs a linear regression of each event against measured power, discards events with $p>0.05$, ranks survivors by Pearson correlation, then picks a compatible subset that the PMU can count simultaneously; NNLS trains the final weights. At runtime, Runmeter uses a moving window that decouples how often counters are read from how long an observation window spans, and evaluates the linear model with fixed-point arithmetic so estimates stay cheap enough for kernel-level use.","core_discovery":"The central discovery is that DVFS-aware power estimation can be reduced to a lookup table of per-subsystem linear models, one entry per sub-system and frequency, with predictors chosen automatically by linear correlation and weights trained by non-negative least squares. Each model has the form $P_d = L_d + \\sum_i (x_i/T) w_i$, where $x_i$ are PMC counts normalized by sampling period, $L_d$ captures leakage, and non-negative weights keep the terms physically meaningful. Because frequency is factored out through the lookup table, the nonlinear voltage-frequency behavior is absorbed into different table entries, and the total power is computed as a simple sum over sub-systems. The paper reports that this approach reaches the stated accuracy on a heterogeneous NVIDIA board and shows that its fixed-point in-kernel implementation loses at most 0.8% relative to floating point.","pith_inferences":["The paper leaves open whether the same LUT structure extends to other accelerators on the same SoC; a natural test is adding the video or deep-learning accelerator as additional entries in $D^*$.","The independence assumption suggests a testable boundary: workloads with extreme frequency asymmetry expose the model's main failure mode, and adding a cross-term or a stall-state feature would likely recover accuracy there.","Because the ground truth is a 200 mW-resolution onboard sensor, the true model ceiling may be better than reported; an external high-resolution measurement setup would settle how much of the 7.5% is sensor-limited.","The selected PMCs themselves could seed a hybrid model, using them as a starting point for architectural refinement rather than as the final black box."],"forward_implications":["The same automated pipeline can be rerun on a new board or after a hardware revision, since only benchmarks and PMC traces are needed, not a manual architectural study.","Because the model is a sum of per-subsystem terms, online estimates expose how much power comes from the CPU and how much from the GPU, enabling task-level attribution.","The fixed-point kernel implementation keeps the model's accuracy loss below 0.8%, so the offline accuracy carries over to online monitoring.","At a 10 Hz sampling rate with under 1% worst-case overhead, the estimates are fast enough to close a DVFS or scheduling control loop in the kernel."],"supporting_citations":[{"why":"Establishes the foundational result that PMC activity correlates with power consumption, motivating the whole approach.","marker":"[11]"},{"why":"Supplies the prior data-driven DVFS-aware counter-based method that this paper generalizes.","marker":"[12]"},{"why":"Provides the decomposable mobile SoC power-modeling baseline the paper compares against.","marker":"[13]"},{"why":"Supplies the CPU PMC-selection and power-modeling technique on ARM cores, defining the CPU accuracy baseline.","marker":"[23]"},{"why":"Shows the trade-off between PMC sampling period and observation window, supporting Runmeter's moving-window design.","marker":"[33]"},{"why":"Provides the in-kernel PMC sampling infrastructure whose low-level hooks Runmeter reuses and extends.","marker":"[34]"},{"why":"Justifies the sub-system independence assumption by showing cross-subsystem nonlinear models add little accuracy.","marker":"[36]"},{"why":"Supplies the heterogeneous CPU/GPU benchmark workloads used to profile, train, and validate the models.","marker":"[39]"},{"why":"Provides the onboard current monitor used as training and validation ground truth, setting the 200 mW sensor resolution.","marker":"[40]"}],"fun_headline_variants":["PMC lookup-table models estimate power to 7.5% error","Kernel power monitoring with 0.7% overhead via PMCs","Hardware counter models achieve 7.5% power estimation error","Runmeter: low-overhead power tracking using PMCs in Linux","DVFS-aware power models from PMCs hit 7.5% accuracy"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing assumption is that the CPU's and GPU's power draw add up independently, so the total is just the sum of the two per-subsystem models; when one sub-system stalls waiting on the other, the model cannot see the interaction and the headline accuracy no longer holds.","fun_headline_variants_meta":{"raw":{"variants":["PMC lookup-table models estimate power to 7.5% error","Kernel power monitoring with 0.7% overhead via PMCs","Hardware counter models achieve 7.5% power estimation error","Runmeter: low-overhead power tracking using PMCs in Linux","DVFS-aware power models from PMCs hit 7.5% accuracy"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00077,"raw_usage":{"total_tokens":3418,"prompt_tokens":959,"completion_tokens":2459,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":575,"completion_tokens_details":{"reasoning_tokens":2365}},"tokens_in":575,"tokens_out":2459,"duration_ms":16658,"temperature":1.0,"reasoning_tokens":2365,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T21:34:02.572194+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a workload at an extreme frequency mismatch on the same board, such as CPU at 2.3 GHz with GPU at 115 MHz, and compare the model's online estimate against the onboard sensor over repeated trials; if the average error is substantially larger than 7.5% while CPU/GPU frequencies are held constant, the independence assumption is the limiting factor.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Establishes the foundational result that PMC activity correlates with power consumption, motivating the whole approach."},{"cited_title":"Mazzola, T","cited_arxiv_id":null,"evidence_quote":"Supplies the prior data-driven DVFS-aware counter-based method that this paper generalizes."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the decomposable mobile SoC power-modeling baseline the paper compares against."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the CPU PMC-selection and power-modeling technique on ARM cores, defining the CPU accuracy baseline."},{"cited_title":"Rodrigues, A","cited_arxiv_id":null,"evidence_quote":"Shows the trade-off between PMC sampling period and observation window, supporting Runmeter's moving-window design."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the in-kernel PMC sampling infrastructure whose low-level hooks Runmeter reuses and extends."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Justifies the sub-system independence assumption by showing cross-subsystem nonlinear models add little accuracy."},{"cited_title":"Che, et al., Rodinia: A benchmark suite for heterogeneous computing, in: 2009 IEEE international symposium on workload characterization (IISWC), IEEE, 2009, pp","cited_arxiv_id":null,"evidence_quote":"Supplies the heterogeneous CPU/GPU benchmark workloads used to profile, train, and validate the models."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the onboard current monitor used as training and validation ground truth, setting the 200 mW sensor resolution."}],"review_version":1}