MaLV-OS: Rethinking the Operating System Architecture for Machine Learning in Virtualized Clouds

Oana Balmau; Stella Bitchebe

REVIEW 4 major objections 5 minor 71 references

MaLV-OS: Rethinking the Operating System Architecture for Machine Learning in Virtualized Clouds

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

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

Pith's one-line read This paper argues that general-purpose OSes throttle machine learning in virtualized clouds, and proposes MaLV-OS, an OS architecture that moves data loading and preprocessing into the kernel and shares GPUs across VMs via…

desk verdict A coherent, well-written position paper with a real but limited GPU-passthrough measurement; the load-bearing OS-for-ML benefit is asserted, not shown, and the paper deserves workshop-style peer review rather than full acceptance. read the letter →

arxiv 2508.03676 v1 pith:4DI6YYTT submitted 2025-08-05 cs.OS cs.LG

Stella Bitchebe , Oana Balmau This is my paper

classification cs.OScs.LG

keywords operatingsystemsmachinelearningvirtualizationGPUkernelmodulesdatapreprocessingMLasaservicecloudcomputing

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

This paper makes the case that the operating system, not the model or the hardware, is the least adapted layer for machine learning in virtualized clouds. It proposes MaLV-OS, an OS architecture designed specifically for ML workloads, whose signature move is to reverse the usual learned-systems direction: instead of using ML to improve the kernel, it uses the kernel to improve ML. The paper backs the motivation with measurements showing that GPU passthrough costs on average 13% training time, reaches 37% for preprocessing-heavy workloads, and lowers GPU utilization by 27% in a VM. MaLV-OS would address this by offloading data loading and preprocessing into the kernel as loadable modules, giving kernel space access to the virtual GPU, and integrating an open-source GPU virtualization layer directly into the hypervisor. If the architecture works as envisioned, ML training in clouds would become faster, GPU resources would be shared rather than dedicated, and models themselves would be simpler.

What carries the argument

The load-bearing mechanism is the MLaaS subsystem built around loadable kernel modules. The user calls an extended syscall API to request a policy; the MLaaS manager loads the corresponding module, which executes data loading and preprocessing in kernel space for the OS-for-ML half, and supplies learned memory-management and CPU-scheduling models for the ML-for-OS half. Micro-LAKE is the enabling microkernel, derived from prior work, that lets these kernel-space components access the virtual GPU. The GPU virtualization layer, placed inside the hypervisor, is what makes the GPU shareable across VMs and completes the architecture.

What would settle it

Implement the OS-for-ML module for a preprocessing-heavy workload such as 3D image segmentation, run it on a VM with GPU passthrough, and compare end-to-end training time and GPU utilization against the same workload on an unmodified Linux guest with a strong user-space pipeline; if the kernel-side version is not faster, the paper's main benefit over user-space optimization is refuted.

Watch

Extended reading notes

Core claim

The paper's central claim is that an ML-specialized OS is both possible and necessary for virtualized clouds. Its architecture, MaLV-OS, contains a microkernel called Micro-LAKE that lets kernel-space code use the virtual GPU, and an MLaaS subsystem with two halves: OS for ML, which moves system-sensitive parts of a model like data loading and preprocessing into loadable kernel modules requested through an extended syscall API, and ML for OS, which runs learned models that help the kernel with memory management and CPU scheduling. The same architecture makes GPU virtualization part of the hypervisor, either by extending the virtio standard (para-vGPU) or by adding a GPU control structure analogous to the CPU's VMCS (full-vGPU). The paper presents its own GPU passthrough measurements as evidence that current virtualization is insufficient: 13% average training time overhead, 37% for a preprocessing-intensive image-segmentation workload, and 27% lower GPU utilization in a VM compared with native. On the paper's own terms, these results justify a dedicated ML OS rather than further patches to a general-purpose one.

Load-bearing premise

The paper's central novel benefit rests on the unmeasured premise that moving data loading and preprocessing into the kernel as loadable modules will speed up execution and simplify models; this is stated as a design choice, without an implementation, benchmark, or kernel-safety analysis.

Editorial extensions

If this is right

End-to-end ML training time in VMs would drop for preprocessing-heavy workloads, since the preprocessing step moves from user space into the kernel instead of competing with the VM's CPU virtualization overhead.
Physical GPUs could be shared and overcommitted across VMs through the open-source hypervisor-level virtualization, raising GPU utilization above the 18-62% range measured with passthrough and lowering per-VM GPU cost.
Models would become simpler because programmers would no longer manage data loading and preprocessing; they would request an MLaaS policy instead.
MLaaS policies could be loaded and unloaded at runtime without recompiling or rebooting the kernel, letting a VM select the policy that fits the workload it is currently running.
Even users who do not offload any model code would benefit from the ML-for-OS side, since learned scheduling and memory management would run underneath unchanged applications.

Reading between the lines

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

If kernel-side preprocessing is faster, the boundary between ML frameworks and OSes is likely to shift, with the OS absorbing data-pipeline work that today lives in user-space loaders; the paper does not explore this architectural consequence.
The paper's proposal runs user-requested ML code in kernel space, which raises isolation and safety concerns that the paper does not evaluate; a production version would need fault containment for these modules, not just load/unload convenience.
The passthrough experiments use V100 GPUs; repeating the same normalized-training-time measurement on newer accelerators would test the paper's expectation that the virtualization gap grows with newer hardware.
A direct comparison of MaLV-OS's kernel-side preprocessing against the strongest user-space pipeline (parallel preprocessing plus training) would isolate whether the OS placement itself, rather than parallelism, is what saves time.

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

Short version: this is a clearly-written position paper that proposes an ML-specialized guest OS, MaLV-OS, built from three known ideas: a microkernel that lets kernel modules use the GPU (LAKE), loadable kernel modules that provide ML policies (Kleio/Lynx-style), and GPU virtualization via virtio or hardware-assisted VMCS-like structures. The authors also report a real GPU passthrough measurement on V100s showing about 13% average overhead, with 3D-UNet at 37% on 8 GPUs. That measurement is the paper's only quantitative content, and it is what the whole architecture is meant to address.

What is genuinely new is the aggregation: I do not know of another paper that puts ML-for-OS and OS-for-ML together into one proposed kernel and explicitly targets virtualized clouds. The framing that no one has used the OS to improve ML is too strong—SpeedyLoader, DALI, Cachew, Pecan, and tf.data are all systems-level optimizations of the ML data pipeline, and the authors cite them. The narrower claim, that no one has proposed a whole OS tailored to ML, is defensible.

The soft spot is load-bearing and the stress-test note names it correctly. Figure 1 compares a KVM guest against a physical host, so the 13% (and 37% for 3D-UNet) is CPU virtualization overhead. The proposed fix—offloading preprocessing into guest-kernel modules—does not remove that overhead, because guest kernel code still runs on vCPUs. The text offers no mechanism (fewer VM exits, a lower-copy path, bypassing host accounting) by which kernel residency is faster than user-space pipelines, and there is no benchmark against SpeedyLoader, DALI, or tf.data. There is also no discussion of fault isolation: a bug in a loadable module can take down the guest. So the OS-for-ML pillar, which is the paper's claimed advance over prior systems-for-ML work, is supported only by assertion.

The GPU full-virtualization vision (para-vGPU, full-vGPU with G-VMCS) is more clearly argued as a research direction, but it is unimplemented.

Who is this for? People working on systems-for-ML and OS design who want a survey of the space plus a concrete research agenda. As a position paper it is fine; as a validation of MaLV-OS benefits it does not deliver. I would send it to referees at a systems workshop (HotOS, APSys), where it would generate useful discussion, but I would not accept it as a full paper without an implementation or at least a simulation. The measurement methodology also needs error bars and repetition before the 13%/37% numbers are load-bearing.

Recommendation: engage with it as a vision paper worth discussing; require evidence before treating any of the performance claims as established.

Referee Report

4 major / 5 minor

Summary. The paper proposes MaLV-OS, an ML-specialized operating system for virtualized clouds, built around three components: Micro-LAKE (a micro-kernel giving kernel-space applications access to GPUs), an MLaaS subsystem that combines "ML for OS" (kernel policies learned with ML) and "OS for ML" (loading parts of the ML pipeline, such as data loading and preprocessing, into kernel modules), and GPU virtualization integrated into the hypervisor via two proposed mechanisms (para-vGPU and full-vGPU). The motivation is an experimental study of GPU passthrough on V100 hardware with three MLPerf workloads, reported in Figures 1 and 2, which shows up to 37% normalized training-time overhead for the preprocessing-intensive 3D-UNet workload and lower GPU utilization in a KVM guest than on native hardware. The paper then presents a conceptual architecture for MaLV-OS. No implementation, prototype, or end-to-end evaluation of MaLV-OS is presented; the only quantitative results are the GPU passthrough measurements used as motivation.

Significance. The problem addressed is real and timely: ML workloads in virtualized clouds do suffer from CPU-side preprocessing bottlenecks and GPU underutilization, and open-source GPU virtualization remains an open challenge. The paper's framing — synthesizing ML-for-OS, OS-for-ML, and GPU virtualization into a single architecture — is a novel way to organize a research agenda, and the passthrough measurements on modern MLPerf workloads are a useful data point. However, the central novel claim, that moving data loading and preprocessing into guest-kernel modules will speed up execution, is not supported by the evidence presented, and the architecture itself is entirely unvalidated. As a systems paper, the contribution is therefore largely a research proposal rather than a demonstrated result; the abstract and takeaways overstate the strength of the support for MaLV-OS's benefits.

major comments (4)

[§4, 'OS for ML'; §3.1, Takeaway] The central architectural claim — that offloading data loading and preprocessing from user-space model code into guest-kernel loadable modules will speed up execution — is not supported by the presented evidence. Figure 1 compares a KVM guest with GPU passthrough against a physical host and therefore isolates CPU-virtualization overhead; it does not measure the user-space vs. kernel-space boundary. Since the guest kernel itself runs on the same virtualized vCPUs, relocating preprocessing into a guest-kernel module does not eliminate the overhead that Figure 1 quantifies. The text provides no mechanism by which kernel residency is faster (e.g., fewer VM exits, a lower-copy data path, or bypass of host accounting), and it does not compare against user-space alternatives such as SpeedyLoader, DALI, or tf.data, which target the same preprocessing bottleneck. Because the OS-for-ML pillar is the main claimed advance over prior systems-for-ML work, this is a load-bearing gap rather than a presentation issue.
[§3.1, 'Systems and hardware' and Figures 1–2] The quantitative support is too thin to carry the paper's motivation. Only one GPU generation (V100) is tested; no repetition counts, error bars, or statistical tests are reported; GPU utilization is read from nvidia-smi without validation against a more direct profiler; and the statement that the overhead should be 'even higher for newer GPUs like A100 or H100' is an unsupported extrapolation. Since Figures 1 and 2 are the only quantitative results, the paper should either restrict its conclusions to V100-class hardware or add measurements on A100/H100 with proper statistical reporting.
[§4, 'Micro-LAKE' and 'MLaaS' paragraphs] The architecture's core components — a kernel background model that continuously learns and dynamically adjusts policies, ML-for-OS models for memory management and CPU scheduling, and user-requested loadable kernel modules for ML — are described only at a conceptual level. There is no design detail on how the background model is trained or updated online, no analysis of the safety or ABI implications of loading user-requested code into the kernel (a module fault can crash the guest), and no feasibility or overhead evaluation. As a result, the paper does not substantiate its claim that MaLV-OS provides benefits over existing user-space data pipelines. If this is intended as a vision/position paper, that should be explicit from the abstract onward, with the empirical sections clearly labeled as motivation rather than validation.
[§4, 'MaLV-OS GPU virtualization' paragraph] The two proposed GPU full-virtualization approaches, para-vGPU (extending virtio) and full-vGPU (a new hardware G-VMCS structure), are core to the paper's cloud-sharing argument, but no feasibility analysis, prototype, overhead estimate, or comparison with existing GPU virtualization systems is provided. In particular, the claim that a new hardware control structure 'G-VMCS' would enable efficient GPU sharing is entirely speculative, and the paper does not show that the cited vPIM approach, which targets processing-in-memory hardware, transfers to GPUs. This part of the proposal should be labeled clearly as long-term speculation, or supported with at least a preliminary study of existing virtio-based GPU virtualization overheads.

minor comments (5)

[§1, paragraph 2] The phrase 'the two most popular operating systems used for ML in the cloud are Microsoft and Linux' should refer to 'Microsoft Windows' rather than the company name.
[§3.1, 'Systems and hardware'] The matching of the Native machine's '64 CPUs' with the VM's '64 vCPUs' is not described; if hyperthreading is enabled, the comparison may not be apples-to-apples, so this should be clarified.
[Figure 2] The figure would benefit from an explanation of how GPU utilization was sampled and aggregated, since instantaneous nvidia-smi readings can misrepresent steady-state utilization.
[References] Reference [9] contains a typo ('Managemnet Library'), reference [20] contains 'Opererating Systems Review' instead of 'Operating Systems Review', and reference [46] uses 'maskrnn-benchmark' instead of 'maskrcnn-benchmark'; these should be corrected.
[§4, 'OS for ML'] The sentence claiming kernel-resident preprocessing will 'speed up its execution' gives no measurable target; the paper should specify the metric (e.g., end-to-end training time, GPU idle time) and the baseline against which improvement is claimed.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: the paper's measurements are external observations, its architectural benefits are asserted rather than derived, and its self-citations to SpeedyLoader and vPIM provide independent empirical support rather than load-bearing circular evidence.

full rationale

MaLV-OS is a vision paper with no fitted parameters, no predictive model, and no derivation chain that reduces to its inputs. The motivating measurements (13% average GPU passthrough overhead in Figure 1, GPU underutilization in Figure 2) are external experimental observations on MLPerf workloads; they do not statistically force any architectural conclusion. The central claim that offloading data loading and preprocessing into the guest kernel will 'simplify the model and speed up its execution' (Section 4) is asserted without a mechanism or benchmark, but it is not derived from the measurements by construction, so it is an unsupported inference rather than circular reasoning. The paper cites the authors' own prior work, SpeedyLoader [52], for the empirical fact that preprocessing can exceed 30% of end-to-end training time; that is an independently published, falsifiable measurement, not a load-bearing self-citation. Similarly, para-vGPU is said to 'follow[] the vPIM technique' [62], an open-source, peer-reviewed system by overlapping authors; this is a design analogy, not a circular justification. The novelty claim that 'no work has taken the opposite direction, i.e., using OS to improve ML' is a literature assertion, not a uniqueness theorem imported from the authors. No equation or definition makes the predicted speedup equivalent to an input by construction; the paper simply lacks the support that would be needed to substantiate its architectural promises. The self-citations are real evidence and do not raise the circularity score beyond the minor level, with no circular step identified.

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

The paper introduces no fitted parameters; it is a design proposal. The central claim rests on several unverified assumptions: that kernel-level data loading/preprocessing is faster, that ML models inside the kernel are safe and beneficial, and that full GPU virtualization can be done without prohibitive overhead. The only empirical input is the GPU passthrough measurement, which is used as motivation rather than as a component of the claimed result.

assumptions (5)

domain assumption Preprocessing can account for more than 30% of end-to-end training time.
Cited from SpeedyLoader [52] in Section 4; this motivates moving preprocessing into the kernel.
ad hoc to paper A kernel-space background model can continuously learn and dynamically adjust OS policies.
Assumed for the MLaaS 'ML for OS' component; no implementation or evidence is provided.
ad hoc to paper Moving model preprocessing into the kernel as loadable modules speeds up execution and simplifies models.
Stated in Section 4 with no prototype, benchmark, or safety analysis.
ad hoc to paper GPU full virtualization via virtio or G-VMCS hardware changes is feasible and beneficial.
Proposed in Section 4; no implementation, overhead estimate, or hardware engagement is described.
domain assumption Sharing GPUs among VMs will increase utilization and lower costs.
Underlies the motivation from Figure 2's GPU underutilization measurements.

invented entities (4)

Micro-LAKE
purpose: Micro-kernel allowing kernel-space applications to access the GPU
Proposed as an extraction of LAKE [22]; no implementation exists in this paper.
MLaaS subsystem
purpose: Loads ML models into the kernel for memory management, CPU scheduling, and user-specified model offloading
Described as loadable kernel modules; no prototype or performance evaluation is provided.
G-VMCS
purpose: GPU virtual machine control structure for hardware-assisted full GPU virtualization
New hardware control structure proposed by analogy to CPU VMCS; no hardware support exists.
para-vGPU and full-vGPU
purpose: Two GPU virtualization approaches integrated into the hypervisor
Concepts based on vPIM [62] and CPU virtualization [14]; not implemented or measured.

how reviews work

0 comments

Cite this review

Pith. "Pith review of MaLV-OS: Rethinking the Operating System Architecture for Machine Learning in Virtualized Clouds." pith.science (2026). https://pith.science/paper/4DI6YYTT

@misc{pith2026250803676,
  author       = {Pith},
  title        = {Pith review of: MaLV-OS: Rethinking the Operating System Architecture for Machine Learning in Virtualized Clouds},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4DI6YYTT}},
  note         = {Machine review of arXiv:2508.03676}
}

read the original abstract

A large body of research has employed Machine Learning (ML) models to develop learned operating systems (OSes) and kernels. The latter dynamically adapts to the job load and dynamically adjusts resources (CPU, IO, memory, network bandwidth) allocation to respond to the actual user demand. What this work has in common is that it utilizes ML to improve kernel decisions. To this day, and to the best of our knowledge, no work has taken the opposite direction, i.e., using OS to improve ML. While some work proposes applying system-level optimizations to ML algorithms, they do not tailor the OS to adapt to the ML context. To address this limitation, we take an orthogonal approach in this paper by leveraging the OS to enhance the performance of ML models and algorithms. We explore the path towards an ML-specialized OS, MaLV-OS. MaLV-OS rethinks the OS architecture to make it specifically tailored to ML workloads, especially in virtualized clouds, which are now widely used to run ML applications. MaLV-OS envisioned architecture includes (1) a micro-kernel, Micro-LAKE, which allows kernel space applications to use the GPU, and (2) an MLaaS (ML as a Service) subsystem that gathers ML models to help Micro-LAKE with memory management and CPU scheduling. MaLV-OS architecture also offloads system-sensitive parts of the models to the OS, to lighten the model complexity and programming, and speed up its execution. Finally, MaLV-OS integrates an open-source GPU virtualization software, merged directly into the hypervisor. For more flexibility, MaLV-OS vision is to enable the virtual machine to dynamically select MLaaS policies that can improve the performance of the model the user is running. Because MLaaS is designed as loadable kernel modules, the MaLV-OS architecture enables the dynamic addition of new capabilities to the MLaaS subsystem.

Figures

Figures reproduced from arXiv: 2508.03676 by the authors.

**Figure 2.** GPU usage in VM and Native, when using 8 [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

**Figure 3.** MaLV-OS architecture, which builds on the LAKE kernel to make the virtual GPU available to the kernel space. MLaaS stands for ML as a Service. The user can offload parts of the model code to MaLV-OS and request them as kernel modules (in green), loaded and unloaded by the MLaaS (ML as a Service) manager. MaLV-OS GPU virtualization. MaLV-OS architecture integrates the GPU virtualization software directly as part of t… view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

71 extracted references · 20 canonical work pages

[1]

[n. d.]. Amazon EC2 P4 Instances. https://aws.amazon.com/fr/ec2/ pricing/. Accessed: May 20, 2025

2025
[2]

[n. d.]. KiTS19 Challenge Dataset. https://kits19.grand-challenge.org/ data/. Accessed: [Jan 12, 2025]

2025
[3]

[n. d.]. NumPy - The fundamental package for scientific computing with Python. https://numpy.org/. Accessed: May 11, 2025

2025
[4]

[n. d.]. NVIDIA Data Loading Library (DALI). https://developer.nvidia. com/dali. Accessed: May 5, 2025

2025
[5]

[n. d.]. Pandas: powerful Python data analysis toolkit. https://pypi. org/project/pandas/. Accessed: May 11, 2025

2025
[6]

[n. d.]. Scikit-learn - Machine Learning in Python. https://scikit- learn.org/stable/. Accessed: May 11, 2025

2025
[7]

[n. d.]. The Top 3 Operating System in 2022; Linux, Windows, and Solaris. https://princetonits.com/blog/operating-system/the-top-3- operating-system-in-2022-linux-windows-and-solaris/. Accessed: May 19, 2025

2022
[8]

[n. d.]. Usage share of operating systems. https://en.wikipedia.org/ wiki/Usage_share_of_operating_systems. Accessed: May 19, 2025

2025

Show all 71 references

[9]

https://developer.nvidia

2020.NVIDIA Managemnet Library (NVML). https://developer.nvidia. com/management-library-nvml Accessed: May 11, 2025

2020
[10]

Zeeshan Ahmed, Saeed Amizadeh, Mikhail Bilenko, Rogan Carr, Wei- Sheng Chin, Yael Dekel, Xavier Dupre, Vadim Eksarevskiy, Senja Filipi, Tom Finley, Abhishek Goswami, Monte Hoover, Scott Inglis, Mat- teo Interlandi, Najeeb Kazmi, Gleb Krivosheev, Pete Luferenko, Ivan Matantsev,...

2019
[11]

Google AI. [n. d.]. Chat with Gemini to supercharge your creativity and productivity. https://store.google.com/intl/en/ideas/categories/ai/. Accessed: May 19, 2025

2025
[12]

Android. [n. d.]. Get the best of Google AI on Android. https://www. android.com/intl/en_ca/ai/. Accessed: May 19, 2025

2025
[13]

Apple. [n. d.]. Apple Intelligence - AI for the rest of us. https://www. apple.com/ca/apple-intelligence/. Accessed: May 19, 2025

2025
[14]

Edouard Bugnion, Vitaly Chipounov, and George Candea. 2013. Light- weight Snapshots and System-level Backtracking. InProceedings of the 14th USENIX Conference on Hot Topics in Operating Systems(Santa Ana Pueblo, New Mexcio)(HotOS’13). USENIX Association, Berkeley, CA, USA, 23–...

2013
[15]

Lienkamp, Thomas Brox, and Olaf Ronneberger

Özgün Çiçek, Ahmed Abdulkadir, Soeren S. Lienkamp, Thomas Brox, and Olaf Ronneberger. 2016. 3D U-Net: Learning Dense Volumetric Segmentation from Sparse Annotation

2016
[16]

Banerjee, Zbigniew T

Jingde Chen, Subho S. Banerjee, Zbigniew T. Kalbarczyk, and Ravis- hankar K. Iyer. 2020. Machine learning for load balancing in the Linux kernel. InProceedings of the 11th ACM SIGOPS Asia-Pacific Workshop on Systems. doi:10.1145/3409963.3410492

2020
[17]

Daube-Witherspoon, S

M.E. Daube-Witherspoon, S. Matej, J.S. Karp, and R.M. Lewitt. 2001. Application of the row action maximum likelihood algorithm with spherical basis functions to clinical PET imaging.IEEE Transactions on Nuclear Science48, 1 (2001), 24–30. doi:10.1109/23.910827

2001 doi
[18]

Docker. [n. d.]. NVIDIA Docker: GPU Server Application Deploy- ment Made Easy. https://developer.nvidia.com/blog/nvidia-docker- gpu-server-application-deployment-made-easy/. Accessed: May 24, 2025

2025
[19]

Thaleia Dimitra Doudali, Sergey Blagodurov, Abhinav Vishnu, Sud- hanva Gurumurthi, and Ada Gavrilovska. 2019. Kleio: A Hybrid Mem- ory Page Scheduler with Machine Intelligence. InProceedings of the 28th International Symposium on High-Performance Parallel and Dis- tributed Com...

2019
[20]

Micah Dowty and Jeremy Sugerman. 2009. GPU virtualization on VMware’s hosted I/O architecture.SIGOPS Opererating Systems Review (2009). doi:10.1145/1618525.1618534

2009
[21]

Alexandra Fedorova, David Vengerov, David Vengerov, and Daniel Doucette. 2007. Operating System Scheduling On Heterogeneous Core Systems. https://api.semanticscholar.org/CorpusID:14823905

2007
[22]

Rossbach

Henrique Fingler, Isha Tarte, Hangchen Yu, Ariel Szekely, Bodun Hu, Aditya Akella, and Christopher J. Rossbach. 2023. Towards a Machine Learning-Assisted Kernel with LAKE. InProceedings of the 28th ACM International Conference on Architectural Support for Programming Languages...

2023 doi
[23]

Chitralekha G and Jyoti M Roogi. [n. d.]. A Quick Review of ML Algorithms. In2021 6th International Conference on Communication and Electronics Systems (ICCES). doi:10.1109/ICCES51350.2021.9488982

2021
[24]

Gaddisa Olani Ganfure, Chun-Feng Wu, Yuan-Hao Chang, and Wei- Kuan Shih. 2020. DeepPrefetcher: A Deep Learning Framework for Data Prefetching in Flash Storage Devices.IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems(2020). doi:10.1109/TCAD.2020.3012173

2020
[25]

Sepideh Goodarzy, Maziyar Nazari, Richard Han, Eric Keller, and Eric Rozner. 2021. SmartOS: towards automated learning and user-adaptive resource allocation in operating systems. InProceedings of the 12th ACM SIGOPS Asia-Pacific Workshop on Systems. doi:10.1145/3476886. 3477519

2021 doi
[26]

Krzysztof Gorgolewski, Christopher Burns, Cindee Madison, Dav Clark, Yaroslav Halchenko, Michael Waskom, and Satrajit Ghosh. 2011. Nipype: A Flexible, Lightweight and Extensible Neuroimaging Data Processing Framework in Python.Frontiers in Neuroinformatics5 (2011). doi:10.3389...

2011 arXiv
[27]

Dan Graur, Damien Aymon, Dan Kluser, Tanguy Albrici, Chandramo- han A Thekkath, and Ana Klimovic. 2022. Cachew: Machine Learning Input Data Processing As A Service. InProceedings of USENIX ATC 22

2022
[28]

Thekkath, and Ana Klimovic

Dan Graur, Oto Mraz, Muyu Li, Sepehr Pourghannad, Chandramo- han A. Thekkath, and Ana Klimovic. 2024. Pecan: Cost-Efficient ML MaLV-OS: Rethinking the Operating System Architecture for Machine Learning in Virtualized Clouds Conference’17, July 2017, Washington, DC, USA Data Pr...

2024
[29]

Schotten

Mohammad Asif Habibi, Bin Han, Merve Saimler, Ignacio Labrador Pavon, and Hans D. Schotten. 2024. Towards an AI/ML-driven SMO Framework in O-RAN: Scenarios, Solutions, and Challenges. https: //arxiv.org/abs/2409.05092

2024 arXiv
[30]

Mingzhe Hao, Levent Toksoz, Nanqinqin Li, Edward Edberg Halim, Henry Hoffmann, and Haryadi S. Gunawi. 2020. LinnOS: Predictability on Unpredictable Flash Storage with a Light Neural Network. In14th USENIX Symposium on Operating Systems Design and Implementation

2020
[31]

Paul Hawkins, Geoff Skillman, Gregory Warren, Benjamin Ellingson, and Matthew Stahl. 2010. Conformer Generation with OMEGA: Algo- rithm and Validation Using High Quality Structures from the Protein Databank and Cambridge Structural Database.Journal of chemical information and ...

2010 doi
[32]

Nicholas Heller, Niranjan Sathianathen, Arveen Kalapara, Edward Walczak, Keenan Moore, Heather Kaluzniak, Joel Rosenberg, Paul Blake, Zachary Rengel, Makinna Oestreich, Joshua Dean, Michael Tradewell, Aneri Shah, Resha Tejpaul, Zachary Edgerton, Matthew Pe- terson, Shaneabbas ...

2020 arXiv
[33]

Nikolopoulos

Cheol-Ho Hong, Ivor Spence, and Dimitrios S. Nikolopoulos. 2017. GPU Virtualization and Scheduling Methods: A Comprehensive Survey. Comput. Surveys(2017). doi:10.1145/3068281

2017 doi
[34]

Shifu Hou, Aaron Saas, Lifei Chen, and Yanfang Ye. 2016. Deep4MalDroid: A Deep Learning Framework for Android Mal- ware Detection Based on Linux Kernel System Call Graphs. In2016 IEEE/WIC/ACM International Conference on Web Intelligence Workshops. doi:10.1109/WIW.2016.040

2016 doi
[35]

Ibrahim and Leonid Oliker

Khaled Z. Ibrahim and Leonid Oliker. 2022. Preprocessing Pipeline Optimization for Scientific Deep Learning Workloads. InIEEE In- ternational Parallel and Distributed Processing Symposium (IPDPS). doi:10.1109/IPDPS53621.2022.00112

2022
[36]

Daeyoun Kang, Tae Joon Jun, Dohyeun Kim, Jaewook Kim, and Daey- oung Kim. 2017. ConVGPU: GPU Management Middleware in Con- tainer Based Virtualized Environment. In2017 IEEE International Con- ference on Cluster Computing (CLUSTER). doi:10.1109/CLUSTER.2017. 17

2017 doi
[37]

George Karypis and Vipin Kumar. 1998. A Fast and High Quality Multi- level Scheme for Partitioning Irregular Graphs.SIAM Journal on Scien- tific Computing20, 1 (1998), 359–392. doi:10.1137/S1064827595287997 arXiv:https://doi.org/10.1137/S1064827595287997

1998 doi
[38]

Pintelas

Sotiris Kotsiantis, Dimitris Kanellopoulos, and P. Pintelas. 2006. Data Preprocessing for Supervised Learning.International Journal of Com- puter Science1 (01 2006), 111–117

2006
[39]

Pintelas

Sotiris Kotsiantis, Dimitris Kanellopoulos, and P. Pintelas. 2006. Data Preprocessing for Supervised Learning.International Journal of Com- puter Science(2006)

2006
[40]

Arezki Laga, Jalil Boukhobza, Michel Koskas, and Frank Singhoff. 2016. Lynx: a learning linux prefetching mechanism for SSD performance model. In2016 5th Non-Volatile Memory Systems and Applications Sym- posium. doi:10.1109/NVMSA.2016.7547186

2016
[41]

Chiyoung Lee, Se-Won Kim, and Chuck Yoo. 2016. VADI: GPU Virtu- alization for an Automotive Platform.IEEE Transactions on Industrial Informatics(2016)

2016
[42]

Belongie, Lubomir D

Tsung-Yi Lin, Michael Maire, Serge J. Belongie, Lubomir D. Bourdev, Ross B. Girshick, James Hays, Pietro Perona, Deva Ramanan, Piotr Doll’a r, and C. Lawrence Zitnick. 2014. Microsoft COCO: Common Objects in Context.CoRR(2014). http://arxiv.org/abs/1405.0312

2014 arXiv
[43]

Andersen, Michael Isard, Mohammad Mahdi Javanmard, Kathryn S

Martin Maas, David G. Andersen, Michael Isard, Mohammad Mahdi Javanmard, Kathryn S. McKinley, and Colin Raffel. 2020. Learning- based Memory Allocation for C++ Server Workloads. InProceedings of the Twenty-Fifth International Conference on Architectural Support for Programming...

2020 doi
[44]

Stefan Maetschke, Ruwan Bandara Tennakoon, Christian Vecchiola, and Rahil Garnavi. 2017. nuts-flow/ml: data pre-processing for deep learning. (2017). arXiv:1708.06046 http://arxiv.org/abs/1708.06046

2017 arXiv
[45]

Takaki Makino, Hank Liao, Yannis Assael, Brendan Shillingford, Basilio Garcia, Otavio Braga, and Olivier Siohan. 2019. Recurrent Neural Network Transducer for Audio-Visual Speech Recognition. InIEEE Automatic Speech Recognition and Understanding Workshop

2019
[46]

Francisco Massa and Ross Girshick. [n. d.]. maskrnn-benchmark: Fast, modular reference implementation of Instance Segmentation and Object Detection algorithms in PyTorch. https://github.com/ facebookresearch/maskrcnn-benchmark. Accessed: May 11, 2025

2025
[47]

Peter Mattson, Christine Cheng, Gregory Diamos, Cody Coleman, Paulius Micikevicius, David Patterson, Hanlin Tang, Gu-Yeon Wei, Peter Bailis, Victor Bittorf, et al. 2020. MlPerf Training Benchmark. Proceedings of Machine Learning and Systems(2020)

2020
[48]

MLCommons. [n. d.]. MLPerf Benchmarking Suite - PyTorch imple- mentation for image segmentation. https://github.com/mlcommons/ training/tree/master/image_segmentation/pytorch. Accessed: [May 5, 2025]

2025
[49]

Derek Gordon Murray, Jirí Simsa, Ana Klimovic, and Ihor Indyk. 2021. tf.data: A Machine Learning Data Processing Framework.Proceedings of the VLDB Endowment(2021)

2021
[50]

Musse and Lama A

Hodan M. Musse and Lama A. Alamro. 2016. Cloud Computing: Ar- chitecture and Operating System. InGlobal Summit on Computer and Information Technology (GSCIT). doi:10.1109/GSCIT.2016.7

2016 doi
[51]

Kishore Kumar

Atul Negi and P. Kishore Kumar. 2005. Applying Machine Learning Techniques to Improve Linux Process Scheduling. InTENCON IEEE Region 10 Conference. doi:10.1109/TENCON.2005.300837

2005
[52]

Rahma Nouaji, Stella Bitchebe, and Oana Balmau. 2024. SpeedyLoader: Efficient Pipelining of Data Preprocessing and Machine Learning Train- ing. InProceedings of the 4th Workshop on Machine Learning and Sys- tems. doi:10.1145/3642970.3655824

2024
[53]

NVIDIA. [n. d.]. NVIDIA Virtual GPU (vGPU) Software. https://docs. nvidia.com/vgpu/index.html. Accessed: May 20, 2025

2025
[54]

Vassil Panayotov, Guoguo Chen, Daniel Povey, and Sanjeev Khudanpur
[55]

Fabio Pianese, Peter Bosch, Alessandro Duminuco, Nico Janssens, Thanos Stathopoulos, and Moritz Steiner. 2010. Toward a Cloud Oper- ating System. In2010 IEEE/IFIP Network Operations and Management Symposium Workshops. doi:10.1109/NOMSW.2010.5486552

2010
[56]

Yiming Qiu, Hongyi Liu, Thomas Anderson, Yingyan Lin, and Ang Chen. 2021. Toward reconfigurable kernel datapaths with learned optimizations. InProceedings of the Workshop on Hot Topics in Operating Systems. doi:10.1145/3458336.3465288

2021
[57]

Thippa Reddy, M

G. Thippa Reddy, M. Praveen Kumar Reddy, Kuruva Lakshmanna, Rajesh Kaluri, Dharmendra Singh Rajput, Gautam Srivastava, and Thar Baker. 2020. Analysis of Dimensionality Reduction Techniques on Big Data.IEEE Access(2020). doi:10.1109/ACCESS.2020.2980942

2020
[58]

Ryan Shea and Jiangchuan Liu. 2013. On GPU pass-through perfor- mance for cloud gaming: Experiments and analysis. In2013 12th An- nual Workshop on Network and Systems Support for Games (NetGames). doi:10.1109/NetGames.2013.6820614 Conference’17, July 2017, Washington, DC, USA ...

2013
[59]

Mehta, Andreas F

Pallav Sudarshan, Neelesh B. Mehta, Andreas F. Molisch, and Jin Zhang. 2006. Channel Statistics-Based RF Pre-Processing with An- tenna Selection.IEEE Transactions on Wireless Communications(2006). doi:10.1109/TWC.2006.256973

2006
[60]

Sukanya Suranauwarat and Hideo Taniguchi. 2001. The design, implementation and initial evaluation of an advanced knowledge- based process scheduler.SIGOPS Operating Systems Reviews(2001). doi:10.1145/506084.506090

2001
[61]

Yusuke Suzuki, Shinpei Kato, Hiroshi Yamada, and Kenji Kono. 2016. GPUvm: GPU Virtualization at the Hypervisor.IEEE Trans. Comput. (2016). doi:10.1109/TC.2015.2506582

2016
[62]

Dufy Teguia, Jiaxuan Chen, Stella Bitchebe, Oana Balmau, and Alain Tchana. 2024. vPIM: Processing-in-Memory Virtualization. InPro- ceedings of the 25th International Middleware Conference. doi:10.1145/ 3652892.3700782

2024
[63]

Tesla. [n. d.]. Autopilot and Full Self-Driving (Supervised). https: //www.tesla.com/support/autopilot. Accessed: May 19, 2025

2025
[64]

Taegeon Um, Byungsoo Oh, Byeongchan Seo, Minhyeok Kweun, Goeun Kim, and Woo-Yeon Lee. 2023. Fastflow: Accelerating Deep Learning Model Training With Smart Offloading of Input Data Pipeline. Proceedings of the VLDB Endowment(2023)

2023
[65]

David Wentzlaff, Charles Gruenwald, Nathan Beckmann, Kevin Modzelewski, Adam Belay, Lamia Youseff, Jason Miller, and Anant Agarwal. 2010. An operating system for multicore and clouds: mecha- nisms and implementation. InProceedings of the 1st ACM Symposium on Cloud Computing. d...

2010
[66]

Wikipedia. [n. d.]. Apple Intelligence. https://en.wikipedia.org/wiki/ Apple_Intelligence. Accessed: May 19, 2025

2025
[67]

Zhiyuan Xu, Jian Tang, Chengxiang Yin, Yanzhi Wang, and Guoliang Xue. 2019. Experience-Driven Congestion Control: When Multi-Path TCP Meets Deep Reinforcement Learning.IEEE Journal on Selected Areas in Communications(2019). doi:10.1109/JSAC.2019.2904358

2019
[68]

Yuqi Xue, Yiqi Liu, and Jian Huang. 2023. System Virtualization for Neural Processing Units. InProceedings of the 19th Workshop on Hot Topics in Operating Systems. doi:10.1145/3593856.3595912

2023
[69]

Chao-Tung Yang, Hsien-Yi Wang, Wei-Shen Ou, Yu-Tso Liu, and Ching- Hsien Hsu. 2012. On implementation of GPU virtualization using PCI pass-through. In4th IEEE International Conference on Cloud Comput- ing Technology and Science Proceedings. doi:10.1109/CloudCom.2012. 6427531

2012 doi
[70]

Younge, John Paul Walters, Stephen Crago, and Geoffrey C

Andrew J. Younge, John Paul Walters, Stephen Crago, and Geoffrey C. Fox. [n. d.]. Evaluating GPU Passthrough in Xen for High Perfor- mance Cloud Computing. InIEEE International Parallel and Distributed Processing Symposium Workshops. doi:10.1109/IPDPSW.2014.97

doi
[2015]

In2015 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP)

Librispeech: An ASR Corpus Based on Public Domain Audio Books. In2015 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP)

Pith tools

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

[1] [1]

[n. d.]. Amazon EC2 P4 Instances. https://aws.amazon.com/fr/ec2/ pricing/. Accessed: May 20, 2025

2025

[2] [2]

[n. d.]. KiTS19 Challenge Dataset. https://kits19.grand-challenge.org/ data/. Accessed: [Jan 12, 2025]

2025

[3] [3]

[n. d.]. NumPy - The fundamental package for scientific computing with Python. https://numpy.org/. Accessed: May 11, 2025

2025

[4] [4]

[n. d.]. NVIDIA Data Loading Library (DALI). https://developer.nvidia. com/dali. Accessed: May 5, 2025

2025

[5] [5]

[n. d.]. Pandas: powerful Python data analysis toolkit. https://pypi. org/project/pandas/. Accessed: May 11, 2025

2025

[6] [6]

[n. d.]. Scikit-learn - Machine Learning in Python. https://scikit- learn.org/stable/. Accessed: May 11, 2025

2025

[7] [7]

[n. d.]. The Top 3 Operating System in 2022; Linux, Windows, and Solaris. https://princetonits.com/blog/operating-system/the-top-3- operating-system-in-2022-linux-windows-and-solaris/. Accessed: May 19, 2025

2022

[8] [8]

[n. d.]. Usage share of operating systems. https://en.wikipedia.org/ wiki/Usage_share_of_operating_systems. Accessed: May 19, 2025

2025