Exploiting Application-to-Architecture Dependencies for Designing Scalable OS

Andrei Irimia; Anzhe Cheng; Chenzhong Yin; Nesreen K. Ahmed; Nikos Kanakaris; Paul Bogdan; Shahin Nazarian; Yao Xiao

REVIEW 4 major objections 5 minor 18 references

Exploiting Application-to-Architecture Dependencies for Designing Scalable OS

T0 review · 4 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A multi-layer network of application, kernel, and hardware dependencies yields reported speedups up to 7.11x over Linux.

desk verdict 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. read the letter →

arxiv 2501.00994 v2 pith:XUYMWJOE submitted 2025-01-02 cs.OS

Yao Xiao , Nikos Kanakaris , Anzhe Cheng , Chenzhong Yin , Nesreen K. Ahmed , Shahin Nazarian , Andrei Irimia , Paul Bogdan This is my paper · ORCID

classification cs.OS

keywords operatingsystemsmulti-corescalabilitymulti-layernetworksprocesspartitioningrun-timemappingmicrokernelinter-processcommunicationapplication-awarescheduling

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

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.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the 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.

The 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.

The 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.

I 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.

Who 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.

Referee Report

4 major / 5 minor

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.

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 (4)

[III (System Setup, Application Performance)] 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.
[II-B, Eqs. (1)-(4)] 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.
[II-C] 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.
[III, Figure 3] 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.

minor comments (5)

[II-B, Eqs. (2)-(3)] 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.
[IV vs II-A] 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.
[III, Figure 3] 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.
[References] 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.
[II-C] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: speedups are measured against external baselines, not generated by the paper's own quality function.

full rationale

No circular step is established by the paper's equations or citations. The compile-time partitioner minimizes the quality function T (Eq. 1), and the run-time mapper uses the same T to estimate execution times for candidate process-to-core mappings, as stated in Section II-C. However, the evaluation does not substitute T for performance: the reported speedups are actual wall-clock execution times measured on hardware, compared against unmodified MINIX 3, Linux 4.18-rc4, and Barrelfish. Therefore, the central claim does not reduce to the optimization objective by construction. The quality function's edge weights w_ij are never specified and T is never validated against measured runtimes, which is a serious reproducibility and correctness risk, but an unspecified or unvalidated objective is not the same as a circular derivation. The self-citations (e.g., Refs. [5], [6], [13], [15], [16]) support background material and general partitioning techniques; no load-bearing result is imported from a self-cited uniqueness theorem or ansatz. The abstract claims 7.11x speedup over Linux on a 128-core system while the body reports up to 5.91x on a 16-core platform, and this inconsistency is noted, but an internal numerical mismatch is not circularity. Accordingly, the circularity score is 0.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The central claim rests on an ad hoc objective function with undefined weights and a greedy optimization that is assumed to minimize it. No independent validation of the objective as a runtime predictor is provided, which is the main circularity burden.

free parameters (3)

Application-layer edge weights w_ij^00 = not specified
The weights dominate the quality function T but no formula is given for computing them from the traced instructions.
Instruction overlap among clusters = not specified
Overlapping clusters replicate instructions between processes; the amount of overlap is not optimized or reported.
Greedy random node order = random
The hierarchical partitioner selects nodes randomly, and the search is not guaranteed to find the stated minimum of T.

assumptions (4)

domain assumption Instruction-level dependencies in the dynamic trace determine the optimal process granularity.
Used throughout Section II-A to justify building the application layer from instruction traces.
ad hoc to paper The quality function T in Eq. (1) is a valid proxy for execution time.
Used in Section II-C to choose same-core vs different-core mappings; no empirical correlation is shown.
ad hoc to paper A greedy algorithm with random node visits minimizes T.
Section II-B claims the hierarchical random-node procedure yields partitions that minimize T, without a proof of optimality.
standard math Amdahl's law in the multicore era can be extended to the multi-layer network objective.
The paper states: 'we extend the Amdahl's law in multi-core platforms to accommodate our model.' Section II-B.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Exploiting Application-to-Architecture Dependencies for Designing Scalable OS." pith.science (2026). https://pith.science/paper/XUYMWJOE

@misc{pith2026250100994,
  author       = {Pith},
  title        = {Pith review of: Exploiting Application-to-Architecture Dependencies for Designing Scalable OS},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XUYMWJOE}},
  note         = {Machine review of arXiv:2501.00994}
}

read the original abstract

With the advent of hundreds of cores on a chip to accelerate applications, the operating system (OS) needs to exploit the existing parallelism provided by the underlying hardware resources to determine the right amount of processes to be mapped on the multi-core systems. However, the existing OS is not scalable and is oblivious to applications. We address these issues by adopting a multi-layer network representation of the dynamic application-to OS-to-architecture dependencies, namely the NetworkedOS. We adopt a compile-time analysis and construct a network representing the dependencies between dynamic instructions translated from the applications and the kernel and services. We propose an overlapping partitioning scheme to detect the clusters or processes that can potentially run in parallel to be mapped onto cores while reducing the number of messages transferred. At run time, processes are mapped onto the multi-core systems, taking into consideration the process affinity. Our experimental results indicate that NetworkedOS achieves performance improvement as high as 7.11x compared to Linux running on a 128-core system and 2.01x to Barrelfish running on a 64-core system.

Figures

Figures reproduced from arXiv: 2501.00994 by the authors.

**Figure 2.** Overview of the multi-layer network construction. We convert high-level languages into the corresponding dynamic low-level instructions. Using code tracing, analysis and profiling, we keep track of instructions in each basic block, analyze dependencies, and profile instructions to form an interconnected multi-layer network. Architecture Layer. In the architecture layer, nodes represent hardware cores, and links rep… view at source ↗

**Figure 3.** (Top) Application speedup comparison. (Bottom left) Execution time on a 2-core machine. (Bottom right) Execution time with a 1KB message. processes, messages are transferred between processes 0 and 1, and between processes 2 and 3 simultaneously. We then vary the number of cores (2 to 32) and message sizes (1KB to 64KB) [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

18 extracted references · 15 canonical work pages

[1]

An analysis of linux scalability to many cores

S. Boyd-Wickizer, A. T. Clements, Y . Mao, A. Pesterev, M. F. Kaashoek, R. Morris, and N. Zeldovich, “An analysis of linux scalability to many cores.” in OSDI, 2010

work page 2010
[2]

Ompar: Automatic parallelization with ai-driven source-to-source compilation,

T. Kadosh, N. Hasabnis, P. Soundararajan, V . A. V o, M. Capota, N. Ahmed, Y . Pinter, and G. Oren, “Ompar: Automatic parallelization with ai-driven source-to-source compilation,” 2024. [Online]. Available: https://arxiv.org/abs/2409.14771

arXiv 2024
[3]

Ompgpt: A generative pre-trained transformer model for¬†openmp,

L. Chen, A. Bhattacharjee, N. Ahmed, N. Hasabnis, G. Oren, V . V o, and A. Jannesari, “Ompgpt: A generative pre-trained transformer model for¬†openmp,” in Euro-Par 2024: Parallel Processing , J. Carretero, S. Shende, J. Garcia-Blas, I. Brandic, K. Olcoz, and M. Schreiber, Eds. Cham: Springer Nature Switzerland, 2024, pp. 121–134

work page 2024
[4]

Your computer is already a distributed system. why isn’t your os?

A. Baumann, S. Peter, A. Sch ¨upbach, A. Singhania, T. Roscoe, P. Barham, and R. Isaacs, “Your computer is already a distributed system. why isn’t your os?” in HotOS, 2009

work page 2009
[5]

The chip is the network: Toward a science of network-on-chip design,

R. Marculescu and P. Bogdan, “The chip is the network: Toward a science of network-on-chip design,” Foundations and Trends® in Electronic Design Automation , 2009

work page 2009
[6]

Self-optimizing and self- programming computing systems: A combined compiler, complex net- works, and machine learning approach,

Y . Xiao, S. Nazarian, and P. Bogdan, “Self-optimizing and self- programming computing systems: A combined compiler, complex net- works, and machine learning approach,” IEEE Transactions on Very Large Scale Integration (VLSI) Systems , vol. 27, no. 6, pp. 1416–1427, 2019

work page 2019
[7]

Liedtke, On micro-kernel construction , 1995, vol

J. Liedtke, On micro-kernel construction , 1995, vol. 29, no. 5

work page 1995
[8]

A. S. Tanenbaum and A. S. Woodhull, Operating systems: design and implementation, 1987, vol. 2

work page 1987

Show all 18 references

[9]

Learning code representations using multifractal-based graph networks,

G. Ma, Y . Xiao, M. Capot ˘a, T. L. Willke, S. Nazarian, P. Bogdan, and N. K. Ahmed, “Learning code representations using multifractal-based graph networks,” in 2021 IEEE International Conference on Big Data (Big Data), 2021, pp. 1858–1866

2021
[10]

Optimizing kernel block memory operations,

M. Calhoun, S. Rixner, and A. L. Cox, “Optimizing kernel block memory operations,” in IEEE 4th Workshop on Memory Performance Issues, 2006

2006
[11]

The impact of operating system structure on memory system performance,

J. B. Chen and B. N. Bershad, “The impact of operating system structure on memory system performance,” in OSR, vol. 27, no. 5, 1994, pp. 120– 133

1994
[12]

Software bug prediction using graph neural networks and graph-based text representations,

I. Siachos, N. Kanakaris, and N. Karacapilidis, “Software bug prediction using graph neural networks and graph-based text representations,” Expert Systems with Applications , vol. 259, p. 125290, 2025. [Online]. Available: https://www.sciencedirect.com/science/article/pii/ S09...

2025
[13]

Plasticity-on-chip design: Ex- ploiting self-similarity for data communications,

Y . Xiao, S. Nazarian, and P. Bogdan, “Plasticity-on-chip design: Ex- ploiting self-similarity for data communications,” IEEE Transactions on Computers, vol. 70, no. 6, pp. 950–962, 2021

2021
[14]

Amdahl’s law in the multicore era,

M. D. Hill and M. R. Marty, “Amdahl’s law in the multicore era,” Computer, vol. 41, no. 7, pp. 33–38, 2008

2008
[15]

A structure-aware framework for learning device placements on computation graphs,

S. Duan, H. Ping, N. Kanakaris, X. Xiao, P. Zhang, P. Kyriakis, N. K. Ahmed, G. Ma, M. Capota, S. Nazarian, T. L. Willke, and P. Bogdan, “A structure-aware framework for learning device placements on computation graphs,” 2024. [Online]. Available: https://arxiv.org/abs/2405.14185

2024 arXiv
[16]

Leveraging reinforcement learning and large language models for code optimization,

S. Duan, N. Kanakaris, X. Xiao, H. Ping, C. Zhou, N. K. Ahmed, G. Ma, M. Capota, T. L. Willke, S. Nazarian, and P. Bogdan, “Leveraging reinforcement learning and large language models for code optimization,” 2023. [Online]. Available: https: //arxiv.org/abs/2312.05657

2023 arXiv
[17]

The multikernel: a new os architecture for scalable multicore systems,

A. Baumann, P. Barham, P.-E. Dagand, T. Harris, R. Isaacs, S. Peter, T. Roscoe, A. Sch¨upbach, and A. Singhania, “The multikernel: a new os architecture for scalable multicore systems,” in SOSP, 2009, pp. 29–44

2009
[18]

Bienia and K

C. Bienia and K. Li, Benchmarking modern multiprocessors. Princeton University Princeton, 2011

2011

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.

[1] [1]

An analysis of linux scalability to many cores

S. Boyd-Wickizer, A. T. Clements, Y . Mao, A. Pesterev, M. F. Kaashoek, R. Morris, and N. Zeldovich, “An analysis of linux scalability to many cores.” in OSDI, 2010

work page 2010

[2] [2]

Ompar: Automatic parallelization with ai-driven source-to-source compilation,

T. Kadosh, N. Hasabnis, P. Soundararajan, V . A. V o, M. Capota, N. Ahmed, Y . Pinter, and G. Oren, “Ompar: Automatic parallelization with ai-driven source-to-source compilation,” 2024. [Online]. Available: https://arxiv.org/abs/2409.14771

arXiv 2024

[3] [3]

Ompgpt: A generative pre-trained transformer model for¬†openmp,

L. Chen, A. Bhattacharjee, N. Ahmed, N. Hasabnis, G. Oren, V . V o, and A. Jannesari, “Ompgpt: A generative pre-trained transformer model for¬†openmp,” in Euro-Par 2024: Parallel Processing , J. Carretero, S. Shende, J. Garcia-Blas, I. Brandic, K. Olcoz, and M. Schreiber, Eds. Cham: Springer Nature Switzerland, 2024, pp. 121–134

work page 2024

[4] [4]

Your computer is already a distributed system. why isn’t your os?

A. Baumann, S. Peter, A. Sch ¨upbach, A. Singhania, T. Roscoe, P. Barham, and R. Isaacs, “Your computer is already a distributed system. why isn’t your os?” in HotOS, 2009

work page 2009

[5] [5]

The chip is the network: Toward a science of network-on-chip design,

R. Marculescu and P. Bogdan, “The chip is the network: Toward a science of network-on-chip design,” Foundations and Trends® in Electronic Design Automation , 2009

work page 2009

[6] [6]

Self-optimizing and self- programming computing systems: A combined compiler, complex net- works, and machine learning approach,

Y . Xiao, S. Nazarian, and P. Bogdan, “Self-optimizing and self- programming computing systems: A combined compiler, complex net- works, and machine learning approach,” IEEE Transactions on Very Large Scale Integration (VLSI) Systems , vol. 27, no. 6, pp. 1416–1427, 2019

work page 2019

[7] [7]

Liedtke, On micro-kernel construction , 1995, vol

J. Liedtke, On micro-kernel construction , 1995, vol. 29, no. 5

work page 1995

[8] [8]

A. S. Tanenbaum and A. S. Woodhull, Operating systems: design and implementation, 1987, vol. 2

work page 1987