{"id":"63c44b26-b3a9-4d5c-93c4-046822908627","arxiv_id":"2501.00994","paper_version":2,"verdict":"REJECT","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"high","formal_verification":"none","parameter_count":3,"one_line_summary":"NetworkedOS uses instruction-level dependency graphs to partition applications into processes and map them to cores, claiming up to 7.11x speedup over Linux, but the supporting evaluation is contradictory.","lead":"NetworkedOS models an application's instructions, the OS kernel, memory, and hardware cores as a multi-layer network, then uses graph partitioning to decide how many processes to create and where to run them. The paper claims large speedups over Linux and Barrelfish, but the evaluation is internally inconsistent and no code or data is released.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The core optimizer is underdetermined: Eq. (1) minimizes T, but the edge weights w_ij that define T are never specified, so the reported speedups cannot be attributed to the proposed partitioning and mapping.","rationale":"The central claim is causal: NetworkedOS improves execution time by partitioning applications into process clusters based on T and by using T at runtime to decide core mappings. For that causal story to be true, T must be an accurate proxy for execution time. The paper never supplies the edge weights that make T concrete, and it never compares T's predictions to measured runtimes. This is not a disagreement with a research community; it is an internal gap in the method. The reported speedups (5.91x vs Linux, 2.01x vs Barrelfish on 16 cores) could be real but produced by different means, such as hand-crafted clusters or a favorable baseline, so without a validated T the headline claim is not supported. The abstract's 7.11x on 128 cores does not appear in the body, which is alarming but is a separate reporting and verifiability issue; even if that experiment were added, the T problem would remain. No code or data is provided, making the missing w_ij definition unfixable by inspection. I therefore agree with the reader's weakest assumption and see no reason to adjust the verdict.","tokens_in":6798,"tokens_out":5064,"duration_ms":50516,"concrete_test":"Obtain the authors' trace-to-weight construction and raw dynamic instruction traces for one benchmark (e.g., FT or IS). Recompute Wseq, Wpar, and Wc from the stated formula, run the greedy partition and runtime mapping, and measure execution times on a fixed platform. Then compare T's predicted best mapping against the measured best mapping across several process-to-core configurations; if the rank correlation is not positive, Eq. (1) does not validate the claimed speedups.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section II-C states 'We use equation (1) to estimate execution times for processes mapped to the same or different cores,' but Eqs. (1)-(4) express T as sums of edge weights w_ij without ever defining how instruction traces produce w_ij. No numerical values, normalization, or calibration are given, and no experiment tests whether T's ranking of partitions matches measured runtimes. Consequently the 'compile-time optimization' and the run-time mapping are not fully specified algorithms; the experiments cannot be reproduced, and the claimed 5.91x/2.01x speedups could result from the authors' manual process choices rather than from minimizing T. The abstract's 7.11x/128-core claim is absent from the body (which reports 5.91x on 16 cores), but fixing that mismatch would not resolve the deeper issue: the quality function is never connected to actual execution time.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes NetworkedOS, an OS design that represents dependencies among application instructions, kernel processes, physical frames, and hardware cores as a multi-layer network. At compile time it partitions the application-layer graph into overlapping clusters intended to become processes, minimizing a quality function T that is claimed to capture sequential work, parallel work, and inter-process communication. At run time, a greedy algorithm maps processes to cores using process interaction and physical-frame information. The evaluation compares NetworkedOS against MINIX 3, Linux 4.18-rc4, and Barrelfish on IPC microbenchmarks and application benchmarks, reporting up to 5.91x speedup over Linux and 2.01x over Barrelfish on a 16-core platform. The abstract further claims 7.11x over Linux on a 128-core system and 2.01x over Barrelfish on a 64-core system.","tokens_in":6969,"tokens_out":6356,"duration_ms":57536,"significance":"The motivation is timely: OS scalability on many-core systems is an open problem, and encoding application-to-OS-to-architecture interactions as a multilayer graph is a creative research direction. The compile-time/runtime split and the attempt to jointly optimize process granularity and core mapping are ambitious and potentially useful. However, the contribution as written is not yet a validated system. The optimization objective is under-specified because the edge weights defining T are never defined, no validation links T to measured execution time, and the headline scalability results in the abstract do not appear in the body. These are not cosmetic issues: without a defined, calibrated objective and a matching many-core evaluation, the reported speedups cannot be attributed to the proposed mechanisms.","major_comments":[{"comment":"The abstract's headline claim of '7.11x compared to Linux running on a 128-core system and 2.01x to Barrelfish running on a 64-core system' is not supported by the evaluation section. The body reports application-level speedups on a '16-core platform' and IPC microbenchmarks on platforms with 2 to 32 cores; no 128-core or 64-core system is described. The System Setup sentence describing a '64-processor system with 2-core 64-bit Intel Core i7-6600U processors' is also ambiguous and inconsistent with the 16-core and 32-core platforms referenced later. The central scalability claim therefore lacks an experimental basis in this manuscript.","section":"III (System Setup, Application Performance)"},{"comment":"The quality function T(s) is the entire basis for compile-time partitioning, but its ingredients are never grounded. Equations (1)-(4) express T as sums of edge weights w_ij, cluster weights W_u, and boundary weights S_u, but the paper never specifies how w_ij are computed from the instruction traces and memory profiling described in Section II-A, nor how they are normalized or calibrated. Definition 2 calls T a quality function 'according to the execution time of applications,' but no derivation or experiment connects T to measured execution time. Consequently the optimization problem is not well posed, and the greedy partition algorithm cannot be reproduced.","section":"II-B, Eqs. (1)-(4)"},{"comment":"The run-time mapping section states, 'We use equation (1) to estimate execution times for processes mapped to the same or different cores.' Since Equation (1) is the same objective minimized at compile time, using it as the run-time estimator makes the evaluation circular: the policy is selected to optimize T, and then the same T is used to predict the benefit of the policy. There is no independent, measured execution-time model. The reported speedups could therefore reflect the authors' implicit choices in defining T rather than an actual reduction in execution time. At minimum, T should be calibrated and validated against measured runtimes on held-out workloads.","section":"II-C"},{"comment":"The performance results are presented as single bars without error bars, number of runs, or statistical tests. Given the well-known variability of OS and application timings, this makes it impossible to judge whether the reported differences are significant or within noise. The empirical claims would need a proper statistical characterization to be acceptable.","section":"III, Figure 3"}],"minor_comments":[{"comment":"The definitions of 'depth' and 'root' used in Equations (2) and (3) are not formal; please clarify how d_u is computed for a cluster in the application-layer graph.","section":"II-B, Eqs. (2)-(3)"},{"comment":"The conclusion says applications, the kernel, and services are compiled into LLVM IR instructions, but Section II-A describes dynamic instruction traces; please clarify the relationship between LLVM IR and the traced instructions.","section":"IV vs II-A"},{"comment":"The caption of Figure 3 does not explain the red dotted line in the top panel (described only in the text as the number of system calls); please add a legend or explicit caption.","section":"III, Figure 3"},{"comment":"Several references appear not to support the surrounding text (e.g., [2], [3], [12]); please re-check the citations and ensure each reference is directly relevant.","section":"References"},{"comment":"The run-time mapping algorithm lists three observations, but does not explain how to resolve conflicts when a process communicates with some processes and is independent of others; please specify the conflict-resolution rule.","section":"II-C"}],"recommendation":"reject","confidential_remarks":"This is a broad-vision paper with interesting ideas, but the evaluation does not support the claims as currently presented. A resubmission could be considered if the authors fully specify the edge-weight model, validate T against measured execution times, eliminate the circularity in the run-time evaluation, and provide a coherent many-core experiment matching the abstract's claims. In its current state, I do not see a path to acceptance without a major rework of the technical content."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"NetworkedOS is a good idea in a weak body. The multi-layer network framing—instructions in an application layer, processes in an interaction layer, physical frames, and cores—is a real abstraction that I haven't seen applied to OS process generation. Using compile-time dependency tracing to group instructions into processes and then mapping those processes with affinity in mind is a sensible direction, and the overlapping clustering idea is worth exploring. The authors also compare against Linux and Barrelfish, which is the right kind of baseline, and they are upfront about why some NAS benchmarks are excluded.\n\nThe trouble is evidence. The abstract promises 7.11x vs Linux on a 128-core system and 2.01x vs Barrelfish on 64 cores, but the body reports up to 5.91x and 2.01x on a 16-core platform and never describes a 128-core run. That mismatch is not a small typo. The system setup is also confusing: \"64-processor system with 2-core Intel i7-6600U processors\" doesn't clearly map to the 16/32-core platforms used in the figures.\n\nThe deeper problem is the quality function. Equations (1)-(4) define T as a sum of edge weights w_ij, but those weights are never defined, never calibrated, and never validated against measured execution times. The run-time mapping section explicitly says it uses Eq. (1) to estimate execution times for processes on the same or different cores. If w_ij is unspecified, the \"optimization\" is under-determined, and the reported speedups can't be attributed to the proposed partitioning and mapping. There is also no code, data, or kernel patch, so nothing is independently checkable, and no error bars anywhere. The citation pattern leans heavily on the authors' own prior network-on-chip work, which is understandable but doesn't broaden the novelty base.\n\nI don't want to overstate the flaws. The paper is not fraudulent; it reads like an early-stage idea with an evaluation that was written too quickly. The benchmark exclusions are disclosed, and the microbenchmarks are standard. The lack of error bars is a real but secondary issue; the undefined model is the load-bearing one.\n\nWho gets value from this: systems researchers thinking about application-aware OS design will find a useful conceptual seed, but not a validated system. I would send it to a serious referee—the idea is too interesting to desk reject—but I would expect a major revision that defines the cost model, reconciles the abstract with the body, and adds at least one reproducible experiment.","headline":"The multi-layer network framing is genuinely worth discussing, but the evidence is too thin: the abstract and body don't agree, and the core cost model is never fully specified.","tokens_in":7519,"tokens_out":3859,"would_cite":false,"duration_ms":35214,"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":"A multi-layer network of application, kernel, and hardware dependencies yields reported speedups up to 7.11x over Linux.","keywords":["operating systems","multi-core scalability","multi-layer networks","process partitioning","run-time mapping","microkernel","inter-process communication","application-aware scheduling"],"falsifier":"Replace the edge weights in the application layer with random values, rerun the partition and mapping on the same benchmarks, and compare execution times; if the speedups over Linux and Barrelfish survive unchanged, the optimization is not the mechanism producing them.","tokens_in":6567,"feed_emoji":"⚙️","tokens_out":10365,"duration_ms":87172,"temperature":0.7,"pith_summary":"The paper advances an operating system design that models, at compile time, the dependencies among application instructions, kernel services, physical memory frames, and hardware cores as one interconnected multi-layer network. A partitioning step groups dynamically executed instructions into overlapping clusters that become processes, balancing parallel work against the cost of inter-process communication. At run time, a greedy mapper assigns those processes to cores according to their communication patterns and memory affinity. If the approach works, the OS stops being a fixed, application-oblivious substrate and adapts its process structure and placement to each workload; the paper reports speedups as high as 7.11x over Linux and 2.01x over Barrelfish.","feed_headline":"Hits 7.11x speedup with an OS built from a dependency network","feed_subtitle":"NetworkedOS partitions app instructions into process clusters and maps them to cores, beating Linux and Barrelfish.","key_machinery":"The load-bearing object is the multi-layer network $G = (V^i, E^{ij}, W^{ij})$, whose four layers are application instructions, processes, physical frames, and cores. Its job is to turn OS decisions into an optimization problem: the compile-time partitioner minimizes the quality function $T$, an extension of the classical multicore speedup model that trades sequential work, parallel work, and inter-cluster message cost, using a greedy hierarchical algorithm; the run-time mapper then uses the process-interaction and physical-frame layers to place communicating or memory-sharing processes nearby while keeping independent processes apart. Overlapping clusters are allowed, so a few shared instructions can be replicated across processes to avoid synchronization.","core_discovery":"The central claim is that application-to-OS-to-architecture dependencies can be captured in a four-layer weighted network—application instructions, process interactions, physical frames, and hardware cores—and that optimizing over this network yields an OS design that outperforms both monolithic and multikernel systems. Concretely, NetworkedOS builds the application layer from dynamic instruction traces, links instructions to the processes that execute them and those processes to the physical frames they touch, and then solves a partition problem with the quality function $T(s) = W_{\\mathrm{seq}} + W_{\\mathrm{par}}/N + W_c$, where $W_{\\mathrm{seq}}$ and $W_{\\mathrm{par}}$ measure sequential and parallel edge weight and $W_c$ measures inter-cluster messages. The paper reports that this partition-and-map recipe reduces IPC messages and execution time in microbenchmarks, and speeds up the benchmark applications by up to 5.91x over Linux and 2.01x over Barrelfish, with the abstract citing 7.11x on a 128-core system.","pith_inferences":["The paper never defines the edge weights $w_{ij}$ that feed the quality function $T$, nor does it compare $T$'s predictions against measured execution times; without that link, the reported gains cannot be cleanly attributed to the optimization rather than to the run-time heuristics.","An ablation that runs the system with random edge weights, with only the runtime mapper, and with only the compile-time partitioner would show which component actually carries the speedups.","The same multi-layer abstraction could serve other goals, such as isolating sensitive process clusters on dedicated cores or minimizing energy, though the paper does not explore those directions."],"forward_implications":["If the reported speedups hold, an OS kernel can be tuned or generated per application from dependency structure instead of being fixed at design time.","The overlap in clusters means selected instructions can be replicated across processes to avoid read-modify-write synchronization, at a cost the quality function is designed to balance.","The run-time placement rules—co-locate processes sharing memory, put communicating processes on adjacent cores, spread independent processes—carry over to network-on-chip and many-core designs.","The measured reductions in IPC and kernel memory block operations imply that both monolithic and multikernel designs carry avoidable overhead on multicore systems."],"supporting_citations":[{"why":"It documents how monolithic kernels lose scalability on many cores, setting up the problem the paper attacks.","marker":"[1]"},{"why":"It argues an OS should behave like a distributed system, motivating the multikernel baseline and the communication-aware mapping.","marker":"[4]"},{"why":"It supplies the MINIX 3 microkernel implementation that is modified and used as a baseline.","marker":"[8]"},{"why":"It provides the multicore speedup model that the quality function T extends.","marker":"[14]"},{"why":"It introduces the multikernel Barrelfish, the scalability baseline NetworkedOS is compared against.","marker":"[17]"},{"why":"It provides the benchmark suites used to measure application speedups.","marker":"[18]"}],"fun_headline_variants":["OS from dependency network hits 7.11x speedup","NetworkedOS: 7.11x faster than Linux on 128 cores","Partition app instructions into clusters for 7x OS boost","Dependency-aware OS outruns Linux by 7.11x","Four-layer network OS: 7.11x speedup over Linux"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The entire speedup argument rests on the estimate $T$ in equation (1) truly predicting how long processes take to run, but the paper never states where the edge weights come from and never compares $T$'s predictions to measured times.","fun_headline_variants_meta":{"raw":{"variants":["OS from dependency network hits 7.11x speedup","NetworkedOS: 7.11x faster than Linux on 128 cores","Partition app instructions into clusters for 7x OS boost","Dependency-aware OS outruns Linux by 7.11x","Four-layer network OS: 7.11x speedup over Linux"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000278,"raw_usage":{"total_tokens":1657,"prompt_tokens":950,"completion_tokens":707,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":566,"completion_tokens_details":{"reasoning_tokens":613}},"tokens_in":566,"tokens_out":707,"duration_ms":6291,"temperature":1.0,"reasoning_tokens":613,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T22:37:09.349625+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Replace the edge weights in the application layer with random values, rerun the partition and mapping on the same benchmarks, and compare execution times; if the speedups over Linux and Barrelfish survive unchanged, the optimization is not the mechanism producing them.","supporting_citations":[{"cited_title":"Bienia and K","cited_arxiv_id":null,"evidence_quote":"It provides the benchmark suites used to measure application speedups."},{"cited_title":"An analysis of linux scalability to many cores","cited_arxiv_id":null,"evidence_quote":"It documents how monolithic kernels lose scalability on many cores, setting up the problem the paper attacks."},{"cited_title":"Your computer is already a distributed system. why isn’t your os?","cited_arxiv_id":null,"evidence_quote":"It argues an OS should behave like a distributed system, motivating the multikernel baseline and the communication-aware mapping."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"It supplies the MINIX 3 microkernel implementation that is modified and used as a baseline."},{"cited_title":"Amdahl’s law in the multicore era,","cited_arxiv_id":null,"evidence_quote":"It provides the multicore speedup model that the quality function T extends."},{"cited_title":"The multikernel: a new os architecture for scalable multicore systems,","cited_arxiv_id":null,"evidence_quote":"It introduces the multikernel Barrelfish, the scalability baseline NetworkedOS is compared against."}],"review_version":1}