Pith. sign in

REVIEW 3 major objections 8 minor 77 references

Interference-free Operating System: A 6 Years' Experience in Mitigating Cross-Core Interference in Linux

T0 review · 3 major / 8 minor · reviewed 2026-08-11 · deepseek-v4-flash

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

Pith's one-line read After six years and 34 kernel fixes, Linux's worst-case cross-core jitter drops 8.7x and schedulability improves up to 11.5x.

desk verdict Genuine industry report with upstream-merged kernel fixes; the 8.7x/11.5x headline overstates attribution, but the RT-Linux comparisons and public patch set justify serious review. read the letter →

arxiv 2412.18104 v1 pith:XGAT4CJL submitted 2024-12-24 cs.OS

Zhaomeng Deng , Ziqi Zhang , Ding Li , Yao Guo , Yunfeng Ye , Yuxin Ren , Ning Jia , Xinwei Hu This is my paper · ORCID
classification cs.OS
keywords cross-coreinterferenceLinuxkernelreal-timesystemscoreisolationworst-caselatencyschedulabilityworkqueueASID
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

Cross-core interference—slowdowns on one core caused by kernel activity on another—is a serious threat to real-time systems, but the paper argues that the operating system itself is a major and under-studied source of that interference. Drawing on six years of industrial experience, the authors identify 34 interference bugs in Linux across task management, resource management, and concurrency management, and they have merged 40 patches into the Linux mainline. Their integrated version, openEuler, reduces worst-case task-activation jitter by a factor of 8.7 compared with vanilla Linux and achieves up to 11.5x better system schedulability. End-to-end latency in cFS and ROS2 drops by 1.6x to 2.1x compared with RT-Linux under the tested workloads. The paper's practical claim is that systematic, category-based auditing of kernel code can eliminate most OS-induced cross-core interference in production systems.

What carries the argument

The load-bearing mechanism is a three-category taxonomy of cross-core interference bugs—task management, resource management, and concurrency management—together with an isolation-aware partition model in which isolated cores run only real-time tasks and non-isolated cores cannot directly interact with them. The argument is carried by the specific fixes: restricting worker-thread activation to the same partition, checking isolation status in core-selection paths, partitioning the ASID space so non-isolated cores never exhaust or lock the ASIDs of isolated cores, flushing per-core queues only when pending work exists, and shrinking seqlock-held critical sections in jiffies updates. These fixes close concrete IPI, TLB-flush, and lock-contention paths that were previously invisible to Linux's fragmented isolation mechanisms.

What would settle it

On the same ARM hardware described in the paper, run the paper's interference workload suite while recording cyclictest on 24 isolated cores for at least 24 hours; if the observed worst-case jitter substantially exceeds 12 us, or if the cFS and ROS2 worst-case latencies do not reproduce the reported reductions, the central claim would need revision. A direct experiment would also intentionally exhaust ASIDs on non-isolated cores and check whether an isolated core's context-switch time remains flat.

Watch

Extended reading notes

Core claim

The central discovery is that the Linux kernel's own subsystems are a principal and removable source of cross-core interference on isolated cores. Through case studies the authors show concrete mechanisms: workqueue operations wake worker threads on isolated cores via IPIs; task migration and irqbalance ignore isolated-core status; ASID exhaustion triggered by non-isolated cores forces TLB flushes and lock contention on isolated cores; NIC uninstall flushes per-core backlog queues everywhere; jiffies synchronization holds seqlocks in long critical sections; and vmstat aggregation runs work on all cores. For each class the paper reports a fix—activation restriction, isolation-aware core selection, partitioned ASID space, on-demand flush, and compressed critical sections—resulting in measured worst-case cyclictest latency of 12 us under heavy interference compared with 104 us for vanilla Linux and 48 us for RT-Linux. The paper further argues that the same three-way taxonomy and lessons generalize to future OS design.

Load-bearing premise

The schedulability improvements assume that the maximum cyclictest latency measured over finite runs (12 us) is a reliable upper bound on task release jitter; if the true worst-case jitter is larger, the reported 11.5x schedulability gains shrink.

Editorial extensions

If this is right

  • Under the paper's interference workload, worst-case cyclictest latency on isolated cores drops from 104 us to 12 us, and worst-case jitter falls by a factor of 8.7 relative to vanilla Linux.
  • EDF and fixed-priority schedulability improve by up to 11.5x over vanilla Linux under the same jitter model, and locking-protocol schedulability reaches up to 8x improvement over vanilla Linux in the read-write-lock scenario.
  • End-to-end worst-case latency in cFS and ROS2 drops by 1.6x to 2.1x relative to RT-Linux, including elimination of the observed 255 ms ROS2 packet-loss event.
  • Because 40 patches are already merged into Linux mainline, downstream distributions can inherit the interference fixes without proprietary kernel forks.
  • The three-category taxonomy gives kernel developers a concrete checklist for locating and fixing similar interference bugs in other subsystems.

Reading between the lines

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

  • Beyond the paper's own results, the same task/resource/concurrency taxonomy could be applied to other monolithic kernels or to hypervisor-based systems, where hidden shared resources are likely to produce analogous interference.
  • The ASID-partitioning fix generalizes to other shared hardware identifiers, such as cache tags or per-device buffers, and could become a design guideline for hardware vendors.
  • The paper's jitter numbers come from finite measurement runs; turning the 12 us value into a certified bound would require either longer stress campaigns or a formal analysis of the patched kernel paths.
  • A testable extension is to replay the paper's interference suite on recent mainline kernels to detect regressions as new subsystems are added.
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.

Referee Report

3 major / 8 minor

Summary. This paper reports six years of industrial experience in identifying and mitigating cross-core performance interference in Linux. It groups the problems into three categories (task management, resource management, and concurrency management), presents representative bugs and their fixes (several claimed to be merged upstream), and distills lessons for future OS design. The evaluation measures worst-case latency with cyclictest and oslat, runs SchedCAT-based schedulability analyses, and benchmarks cFS and ROS2 end-to-end. The headline claims are an 8.7x reduction in worst-case jitter and up to an 11.5x improvement in schedulability, with smaller but still substantial improvements over RT-Linux.

Significance. If the quantitative claims survive scrutiny, this is a valuable industrial experience report with concrete, inspectable kernel patches and a plausible demonstration that cross-core OS interference can be systematically reduced. Strengths of the paper include that several fixes are backed by upstream commit references, the measurements are internally consistent, the evaluation compares against external baselines rather than fitting parameters to its own output, and the schedulability analysis uses standard tools (SchedCAT, Audsley RTA, ILP-based blocking-time analysis). The main weaknesses are that the headline numbers conflate the authors' patches with PREEMPT_RT and other distribution-level changes, and that the schedulability analysis treats finite-run sample maxima as deterministic worst-case jitter bounds. These issues are load-bearing for the paper's central quantitative contribution, so the significance is currently overstated.

major comments (3)
  1. [§V Experimental Setup; Abstract] The abstract and conclusions claim an 8.7x jitter reduction and up to an 11.5x schedulability improvement, but these numbers compare openEuler against Vanilla Linux 5.10. The paper states in §V that openEuler integrates both RT-Linux (PREEMPT_RT) and the authors' kernel modifications, so the comparison with Vanilla Linux does not isolate the authors' contribution; it conflates their fixes with the PREEMPT_RT patch set and any other openEuler changes. The comparison that does isolate the contribution is openEuler versus RT-Linux, which yields a 4.0x jitter reduction and up to a 3.5x schedulability improvement. The headline claims should be reframed around the RT-Linux comparison, or the evaluation should add a configuration that applies only the authors' patches on top of RT-Linux to separate the two effects.
  2. [§V-C, Table II] The schedulability analysis in §V-C uses the maximum cyclictest latency observed over finite runs (12 us for openEuler, 48 us for RT-Linux, 104 us for Vanilla Linux) as a deterministic release-jitter bound for every task. This is a sample maximum, not a verified worst-case bound; calling the model 'conservative' is therefore incorrect, since the true worst-case jitter could be larger than the measured maximum. The reported schedulability improvements, including the 11.5x figure, are directly sensitive to this input value. The paper needs either a sensitivity analysis across a range of jitter values or a statistically justified bound (e.g., many repeated trials with confidence intervals, or an extreme-value analysis) before the schedulability claims can be considered robust.
  3. [§III; References [35]-[47]] The paper claims that 34 cross-core interference bugs were fixed and that 40 patches were incorporated into the Linux mainline, but only about 12 commits are cited in the reference list, and some of those (e.g., the perf top fixes in [37] and [38]) are not obviously cross-core interference fixes. Without a complete mapping from each of the 34 bugs to its upstream commit, workaround, or private patch, the central claim that 'our enhancements' produce the measured improvements cannot be independently verified. Please add a table listing all 34 bugs, their categories, the affected subsystems, and the corresponding upstream commit or workaround status.
minor comments (8)
  1. [Abstract] The phrase 'Compared to the version without our improvements' is ambiguous; the actual comparisons are against Vanilla Linux and RT-Linux, which should be stated explicitly.
  2. [§V-B, Figure 6] The sentence 'the worst-case latency of 50 us reflects the ground truth' is confusingly phrased; it should say that the measurement at the 50 us wake-up period is the value reported in Table II.
  3. [§IV-E] The phrase 'subtitle cross-core interference bugs' should read 'subtle cross-core interference bugs'.
  4. [§V-D] The word 'robostic' should be 'robotic'.
  5. [Throughout] The unit 'us' should be typeset as 'µs' or 'μs' consistently in text and figures.
  6. [References] Several reference URLs contain line breaks or are malformed (e.g., [27], [28], [29]) and should be cleaned up and formatted as proper hyperlinks.
  7. [§IV-A] The phrase 'we despairingly found' is informal for a journal paper; 'we found' would be more appropriate.
  8. [Figure 10] The abbreviation 'RTLinux' in the figure legend should be 'RT-Linux' to match the text, and the scenario abbreviations (SN, CD, MB, WM) should be expanded in the caption or footnote for readability.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's quantitative claims rest on external benchmark measurements and standard schedulability analysis, not on self-referential definitions or fitted predictions.

full rationale

The paper's central claims are empirical evaluations against external baselines, not derivations from a fitted model. The 8.7x worst-case jitter reduction is a measured cyclictest maximum-latency comparison (Table II and Figure 6a), and the schedulability improvements in Section V-C follow by feeding those measured maximum latencies into SchedCAT, an independently developed schedulability analysis toolkit. No prediction in the paper is equivalent by construction to an input: the jitter values are measured, not solved for from the schedulability results. The only self-referential items are citations to the authors' own upstream kernel patches (references 35-47); these are concrete commits with stable kernel.org identifiers and are externally verifiable artifacts, so they do not constitute an unverified self-citation chain. The acknowledged comparison confound (openEuler includes PREEMPT_RT and other distribution changes, so the 8.7x and 11.5x figures over vanilla Linux do not isolate the authors' 34 fixes) is a threat to causal attribution, not a circularity, and the paper also reports the isolating openEuler-versus-RT-Linux comparisons (4.0x jitter, up to 3.5x schedulability). Similarly, using finite-run cyclictest sample maxima as release-jitter bounds is an empirical validation limitation, not a definitional reduction. Accordingly, no circular step can be exhibited, and the appropriate score is 0.

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

The quantitative claims rest on measured latency values and a schedulability model that treats those measurements as worst-case release jitter; these are domain assumptions rather than formally verified bounds. The only hand-chosen numeric design parameter that could affect correctness is the size of the reserved ASID subspace, which is not disclosed. No new physical or abstract entities are introduced.

free parameters (1)
  • ASID reserved subspace size = not disclosed
    The ASID isolation fix in §III-B1 partitions the ASID space but does not specify how many ASIDs are reserved for isolated cores. The guarantee that non-isolated cores never exhaust the reserved set depends on this number exceeding the bounded process count of real-time partitions, which is asserted but not quantified.
assumptions (5)
  • domain assumption Applications on the real-time partition satisfy bounded WCET and use real-time synchronization protocols.
    Stated in §II-C system model; simplifies the analysis to OS-induced interference.
  • domain assumption Tasks on non-isolated cores never directly communicate with tasks on isolated cores, and there is no shared memory or other dependency between partitions.
    Stated in §II-C; ensures any cross-core interference is mediated by the OS kernel.
  • domain assumption The measured maximum latency from finite cyclictest/oslat runs is a valid bound on task release jitter for schedulability analysis.
    Invoked in §V-C when setting release jitter to the values of Table II; not statistically verified as a true worst-case bound.
  • domain assumption The manually selected interference workload in Table IV represents a fair stress of worst-case kernel interference.
    Workloads are hand-picked and bound to non-isolated cores; no evidence is provided that they are exhaustive or truly worst-case.
  • domain assumption Hardware resource partitioning (memory, cache, devices, bus) is complete enough that remaining interference on isolated cores is solely from the kernel.
    Assumed in §II-C and §V experimental setup; residual hardware interference would weaken attribution, though relative comparisons between systems would remain valid.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Interference-free Operating System: A 6 Years' Experience in Mitigating Cross-Core Interference in Linux." pith.science (2026). https://pith.science/paper/XGAT4CJL

@misc{pith2026241218104,
  author       = {Pith},
  title        = {Pith review of: Interference-free Operating System: A 6 Years' Experience in Mitigating Cross-Core Interference in Linux},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XGAT4CJL}},
  note         = {Machine review of arXiv:2412.18104}
}
read the original abstract

Real-time operating systems employ spatial and temporal isolation to guarantee predictability and schedulability of real-time systems on multi-core processors. Any unbounded and uncontrolled cross-core performance interference poses a significant threat to system time safety. However, the current Linux kernel has a number of interference issues and represents a primary source of interference. Unfortunately, existing research does not systematically and deeply explore the cross-core performance interference issue within the OS itself. This paper presents our industry practice for mitigating cross-core performance interference in Linux over the past 6 years. We have fixed dozens of interference issues in different Linux subsystems. Compared to the version without our improvements, our enhancements reduce the worst-case jitter by a factor of 8.7, resulting in a maximum 11.5x improvement over system schedulability. For the worst-case latency in the Core Flight System and the Robot Operating System 2, we achieve a 1.6x and 1.64x reduction over RT-Linux. Based on our development experience, we summarize the lessons we learned and offer our suggestions to system developers for systematically eliminating cross-core interference from the following aspects: task management, resource management, and concurrency management. Most of our modifications have been merged into Linux upstream and released in commercial distributions.

Figures

Figures reproduced from arXiv: 2412.18104 by the authors.

Figure 1
Figure 1. Latency distribution of cyclictest on an idle system. synchronization mechanism, 4) implementing programming features that are helpful for program analysis and verifica￾tion. We also discuss our experience of interacting with the Linux community. We believe that our experience sharing is valuable to application developers, OS designers, and system researchers. With years of development and improvement, we signifi￾ca… view at source ↗
Figure 2
Figure 2. System model. B. Hypervisor Approach There is a trend within the real-time community of utilizing hypervisors, with real-time operating systems (RTOSes) or Linux running on top of them. The two major flaws of Linux system interference isolation mentioned above can be easily overcome through hypervisors. But in practice, many scenarios (e.g. Robot Operating System [31] and edge computing) still have to use Linux-base… view at source ↗
Figure 3
Figure 3. Cross-core interference of workqueue. is under discussion with the community [46]. 9 issues are worked around by restricting applications behavior and system usage. 3 fixes are maintained privately due to business needs. All fixes are deployed in our production environment and delivered to millions of servers and devices. We summarize cross-core interference bugs into three categories based on their functionality: t… view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: The process of inter-core interference caused by ASID exhaustion and TLB refresh. to each process and is used to differentiate between virtual address spaces. The OS uses ASID to identify the correct mapping and does not flush all the TLB entries when switching context…
Figure 5
Figure 5. Figure 5: interference captured on an idle isolated core. A. Interference Workloads To stress the kernel and obtain the worst-case performance of real-time applications, we introduce a fair amount of interference workloads on the non-isolated cores. Table IV describes all the in…
Figure 6
Figure 6. Figure 6: Measured maximum latency of cyclictest. 100 102 104 106 108 0 20 40 60 80 100 120 Frequency Latency (us) Vanilla Linux RT-Linux openEuler (a) cyclctest 100 102 104 106 108 1010 0 10 20 30 40 50 60 Frequency Latency (us) (b) oslat [PITH_FULL_IMAGE:figures/full_fig_p010…
Figure 8
Figure 8. Figure 8: System schedulability of different scheduling algorithms and lock protocols. MCS lock [4] and the reader-writer lock [70]. For MCS, each task has a unique lock. For the reader-writer lock, each reader has a unique lock, and all writers share a single lock. Our experime…
Figure 9
Figure 9. Figure 9: Latency distribution of cFS. 200000 300000 0 1000 2000 3000 4000 5000 SN CD MB WM \\\ 255944 Latency (us) RTLinux w/o interf RTLinux w/ interf openEuler w/ interf 2069 644 4536 1483 2317 983 4870 2029 601 4371 1429 [PITH_FULL_IMAGE:figures/full_fig_p012_9.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

77 extracted references · 76 canonical work pages

  1. [37]

    Linux patch perf top: Expand the range of multithreaded phase

    L. Hangliang, “Linux patch perf top: Expand the range of multithreaded phase.” [Online]. Available: https://git.kernel.org/pub/scm/linux/kernel/ git/torvalds/linux.git/commit/?id=eab5051788f6111adb88268a784af0c9 81616579

    work page

  2. [38]

    Linux patch perf top: Fix rare segfault in thread comm len

    L. Wenyu, “Linux patch perf top: Fix rare segfault in thread comm len.” [Online]. Available: https://git.kernel.org/pub/scm/linux/kernel/git/torv alds/linux.git/commit/?id=eab5051788f6111adb88268a784af0c9816165 79

    work page

  3. [1]

    An empirical survey-based study into industry practice in real-time systems,

    B. Akesson, M. Nasri, G. Nelissen, S. Altmeyer, and R. I. Davis, “An empirical survey-based study into industry practice in real-time systems,” in 2020 IEEE Real-Time Systems Symposium (RTSS’20) , 2020

    work page 2020

  4. [2]

    A study of predictable execution models implementation for industrial data-flow applications on a multi-core platform with shared banked memory,

    M. Schuh, C. Maiza, J. Goossens, P. Raymond, and B. D. de Dinechin, “A study of predictable execution models implementation for industrial data-flow applications on a multi-core platform with shared banked memory,” in2020 IEEE Real-Time Systems Symposium (RTSS’20), 2020

    work page 2020

  5. [3]

    R-tod: Real- time object detector with minimized end-to-end delay for autonomous driving,

    W. Jang, H. Jeong, K. Kang, N. Dutt, and J.-C. Kim, “R-tod: Real- time object detector with minimized end-to-end delay for autonomous driving,” in 2020 IEEE Real-Time Systems Symposium (RTSS’20), 2020

    work page 2020

  6. [4]

    Burns and R

    A. Burns and R. I. Davis, Mixed Criticality Systems - A Review : (13th Edition, February 2022) , February 2022. [Online]. Available: https://eprints.whiterose.ac.uk/183619/

    work page 2022

  7. [5]

    A virtualized separation kernel for mixed criticality systems,

    Y . Li, R. West, and E. Missimer, “A virtualized separation kernel for mixed criticality systems,” in Proceedings of the 10th ACM SIG- PLAN/SIGOPS International Conference on Virtual Execution Environ- ments (VEE’14), 2014

    work page 2014

  8. [6]

    Edf-vd scheduling of mixed-criticality systems with degraded quality guarantees,

    D. Liu, J. Spasic, N. Guan, G. Chen, S. Liu, T. Stefanov, and W. Yi, “Edf-vd scheduling of mixed-criticality systems with degraded quality guarantees,” in 2016 IEEE Real-Time Systems Symposium (RTSS’16) , 2016

    work page 2016

Show all 77 references
  1. [7]

    A ros 2 response-time analysis exploiting starvation freedom and execution- time variance,

    T. Blaß, D. Casini, S. Bozhko, and B. B. Brandenburg, “A ros 2 response-time analysis exploiting starvation freedom and execution- time variance,” in 2021 IEEE Real-Time Systems Symposium (RTSS’21), 2021

    2021

  2. [8]

    Real-time scheduling and analysis of processing chains on multi-threaded executor in ros 2,

    X. Jiang, D. Ji, N. Guan, R. Li, Y . Tang, and Y . Wang, “Real-time scheduling and analysis of processing chains on multi-threaded executor in ros 2,” in 2022 IEEE Real-Time Systems Symposium (RTSS’22), 2022

    2022

  3. [9]

    Cost and benefit of separate address spaces in real-time operating systems,

    F. Mehnert, M. Hohmuth, and H. Hartig, “Cost and benefit of separate address spaces in real-time operating systems,” in 23rd IEEE Real-Time Systems Symposium (RTSS’02). , 2002

    2002

  4. [10]

    Timing analysis of a protected operating system kernel,

    B. Blackham, Y . Shi, S. Chattopadhyay, A. Roychoudhury, and G. Heiser, “Timing analysis of a protected operating system kernel,” in Proceedings of the 2011 IEEE 32nd Real-Time Systems Symposium (RTSS’11), 2011

    2011

  5. [11]

    Real-time synchronization on multiprocessors: To block or not to block, to suspend or spin?

    B. B. Brandenburg, J. M. Calandrino, A. Block, H. Leontyev, and J. H. Anderson, “Real-time synchronization on multiprocessors: To block or not to block, to suspend or spin?” in 2008 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS’08) , 2008

    2008

  6. [12]

    Scalable memory reclamation for multi-core, real-time systems,

    Y . Ren, G. Liu, G. Parmer, and B. Brandenburg, “Scalable memory reclamation for multi-core, real-time systems,” in 2018 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS’18) , 2018

    2018

  7. [13]

    Address- ing multi-core timing interference using co-runner locking,

    H. Kim, D. de Niz, B. Andersson, M. Klein, and J. Lehoczky, “Address- ing multi-core timing interference using co-runner locking,” in 2021 IEEE Real-Time Systems Symposium (RTSS’21) , 2021

    2021

  8. [14]

    An isolation scheduling model for multicores,

    P. Huang, G. Giannopoulou, R. Ahmed, D. B. Bartolini, and L. Thiele, “An isolation scheduling model for multicores,” in2015 IEEE Real-Time Systems Symposium (RTSS’15) , 2015

    2015

  9. [15]

    Global scheduling not required: Simple, near-optimal multiprocessor real-time scheduling with semi-partitioned reservations,

    B. B. Brandenburg and M. G ¨ul, “Global scheduling not required: Simple, near-optimal multiprocessor real-time scheduling with semi-partitioned reservations,” in 2016 IEEE Real-Time Systems Symposium (RTSS’16) , 2016

    2016

  10. [16]

    Maracas: A real-time multicore vcpu scheduling framework,

    Y . Ye, R. West, J. Zhang, and Z. Cheng, “Maracas: A real-time multicore vcpu scheduling framework,” in2016 IEEE Real-Time Systems Symposium (RTSS’16), 2016

    2016

  11. [17]

    Fjos: Practical, predictable, and efficient system support for fork/join parallelism,

    Q. Wang and G. Parmer, “Fjos: Practical, predictable, and efficient system support for fork/join parallelism,” in 2014 IEEE 19th Real-Time and Embedded Technology and Applications Symposium (RTAS’14) , 2014

    2014

  12. [18]

    Randomized work stealing for large scale soft real-time systems,

    J. Li, S. Dinh, K. Kieselbach, K. Agrawal, C. Gill, and C. Lu, “Randomized work stealing for large scale soft real-time systems,” in 2016 IEEE Real-Time Systems Symposium (RTSS’16) , 2016

    2016

  13. [19]

    Improving prediction accuracy of memory interferences for multicore platforms,

    C. Courtaud, J. Sopena, G. Muller, and D. Gracia P ´erez, “Improving prediction accuracy of memory interferences for multicore platforms,” in 2019 IEEE Real-Time Systems Symposium (RTSS’19) , 2019

    2019

  14. [20]

    Taming non-blocking caches to improve isolation in multicore real-time systems,

    P. K. Valsan, H. Yun, and F. Farshchi, “Taming non-blocking caches to improve isolation in multicore real-time systems,” in 2016 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS’16), 2016

    2016

  15. [21]

    Predictable interrupt management and schedul- ing in the composite component-based system,

    G. Parmer and R. West, “Predictable interrupt management and schedul- ing in the composite component-based system,” in 2008 Real-Time Systems Symposium (RTSS’08) , 2008

    2008

  16. [22]

    Chaos: a system for criticality-aware, multi-core coordination,

    P. K. Gadepalli, G. Peach, G. Parmer, J. Espy, and Z. Day, “Chaos: a system for criticality-aware, multi-core coordination,” in 2019 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS’19), 2019

    2019

  17. [23]

    Linux’s processor affinity api, refined: Shifting real-time tasks towards higher schedulabil- ity,

    F. Cerqueira, A. Gujarati, and B. B. Brandenburg, “Linux’s processor affinity api, refined: Shifting real-time tasks towards higher schedulabil- ity,” in 2014 IEEE Real-Time Systems Symposium (RTSS’14) , 2014

    2014

  18. [24]

    Predictable communication and migration in the quest-v separation kernel,

    Y . Li, R. West, Z. Cheng, and E. Missimer, “Predictable communication and migration in the quest-v separation kernel,” in 2014 IEEE Real-Time Systems Symposium (RTSS’14) , 2014

    2014

  19. [25]

    The thundering herd: Amplifying kernel interference to attack response times,

    S. Mergendahl, S. Jero, B. C. Ward, J. Furgala, G. Parmer, and R. Skowyra, “The thundering herd: Amplifying kernel interference to attack response times,” in 2022 IEEE 28th Real-Time and Embedded Technology and Applications Symposium (RTAS’22) , 2022

    2022

  20. [26]

    Predictable virtualization on memory protection unit-based microcontrollers,

    R. Pan, G. Peach, Y . Ren, and G. Parmer, “Predictable virtualization on memory protection unit-based microcontrollers,” in 2018 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS’18), 2018

    2018

  21. [27]

    Linux patch discussion about task isolation

    A. Belits, “Linux patch discussion about task isolation.” [Online]. Available: https://lore.kernel.org/netdev/3443bdf4ff557331c39a99b133d efee56452be48.camel@marvell.com/T/

  22. [28]

    Dropping the timer tick — for real this time

    J. Corbet, “Dropping the timer tick — for real this time.” [Online]. Available: https://lwn.net/Articles/659490/

  23. [29]

    Cyclictest, https://wiki.linuxfoundation.org/realt ime/documentation/howto/tools/cyclictest/start,

    L. F. R.-T. L. Project, “Cyclictest, https://wiki.linuxfoundation.org/realt ime/documentation/howto/tools/cyclictest/start,” 2021

    2021

  24. [30]

    core flight system (cfs),

    NASA, “core flight system (cfs),” 2021. [Online]. Available: https: //cfs.gsfc.nasa.gov/

    2021

  25. [31]

    Robot operating system 2: Design, architecture, and uses in the wild,

    S. Macenski, T. Foote, B. Gerkey, C. Lalancette, and W. Woodall, “Robot operating system 2: Design, architecture, and uses in the wild,” Science Robotics, vol. 7, no. 66, p. eabm6074, 2022. [Online]. Available: https://www.science.org/doi/abs/10.1126/scirobotics.abm6074

    2022 doi

  26. [32]

    Urllc and embb in 5g industrial iot: A survey,

    B. S. Khan, S. Jangsher, A. Ahmed, and A. Al-Dweik, “Urllc and embb in 5g industrial iot: A survey,” IEEE Open Journal of the Communications Society, vol. 3, pp. 1134–1163, 2022

    2022

  27. [33]

    [Online]

    5G is all about Speed & Latency! Huawei Enterprise Support. [Online]. Available: https://forum.huawei.com/enterprise/en/5g-is-all-about-speed -latency/thread/667260360132018176-667213872962088960

  28. [34]

    SAMSUNG Research

    5G vision white paper. SAMSUNG Research. [Online]. Available: https://images.samsung.com/is/content/samsung/p5/global/business/net works/insights/white-paper/5g-vision/global-networks-insight-samsung -5g-vision-2.pdf

  29. [35]

    Linux patch arm64: mm: Use asid feature macro for cheanup

    Y . Yunfeng, “Linux patch arm64: mm: Use asid feature macro for cheanup.” [Online]. Available: https://git.kernel.org/pub/scm/linux/ker nel/git/torvalds/linux.git/commit/?id=386a74677be13175b5626f094ef3 7808c45f48b8

  30. [36]

    Linux patch arm64: mm: Rename asid2idx to ctxid2asid

    ——, “Linux patch arm64: mm: Rename asid2idx to ctxid2asid.” [Online]. Available: https://git.kernel.org/pub/scm/linux/kernel/git/torval ds/linux.git/commit/?id=a3a5b763410c7bceacf41a52071134d9dc26202a

  31. [39]

    Linux patch tick/nohz: Update idle exittime on actual idle exit

    Y . Yunfeng, “Linux patch tick/nohz: Update idle exittime on actual idle exit.” [Online]. Available: https://git.kernel.org/pub/scm/linux/ker nel/git/torvalds/linux.git/commit/?id=96c9b90396f9ab6caf13b4ebf000 95818ac53b7f

  32. [40]

    Linux patch tick/nohz: Conditionally restart tick on idle exit

    ——, “Linux patch tick/nohz: Conditionally restart tick on idle exit.” [Online]. Available: https://git.kernel.org/pub/scm/linux/kernel/git/torval ds/linux.git/commit/?id=a5183862e76fdc25f36b39c2489b816a5c66e2e5

  33. [41]

    Linux patch tick/sched: Release seqcount before invoking calc load global

    ——, “Linux patch tick/sched: Release seqcount before invoking calc load global.” [Online]. Available: https://git.kernel.org/pub/scm/l inux/kernel/git/torvalds/linux.git/commit/?id=896b969e6732b68ee3c12a e4e1aeddf5db99bc46

  34. [42]

    Linux patch tick/sched: Reduce seqcount held scope in tick do update jiffies64

    ——, “Linux patch tick/sched: Reduce seqcount held scope in tick do update jiffies64.” [Online]. Available: https://git.kernel.org/pub /scm/linux/kernel/git/torvalds/linux.git/commit/?id=94ad2e3cedb82af0 34f6d97c58022f162b669f9b

  35. [43]

    Linux patch workqueue: Kick a worker based on the actual activation of delayed works

    ——, “Linux patch workqueue: Kick a worker based on the actual activation of delayed works.” [Online]. Available: https: //git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id= 01341fbd0d8d4e717fc1231cdffe00343088ce0b

  36. [44]

    Linux patch arm64: psci: Reduce the waiting time for cpu psci cpu kill

    ——, “Linux patch arm64: psci: Reduce the waiting time for cpu psci cpu kill.” [Online]. Available: https://git.kernel.org/pub/scm/l inux/kernel/git/torvalds/linux.git/commit/?id=bfcef4ab1d7ee8921bc322 109b1692036cc6cbe0

  37. [45]

    Linux patch genirq: Prevent null pointer dereference in resend irqs

    ——, “Linux patch genirq: Prevent null pointer dereference in resend irqs.” [Online]. Available: https://git.kernel.org/pub/scm/linux/k ernel/git/torvalds/linux.git/commit/?id=eddf3e9c7c7e4d0707c68d1bb2 2cc6ec8aef7d4a

  38. [46]

    Support asid isolation mechanism

    ——, “Support asid isolation mechanism.” [Online]. Available: https://lwn.net/Articles/911472/

  39. [47]

    irqbalance patch add strlen checking for IRQBAL- ANCE BANNED CPUS

    ——, “irqbalance patch add strlen checking for IRQBAL- ANCE BANNED CPUS.” [Online]. Available: https://github.com/I rqbalance/irqbalance/commit/731429f207577236f8ce42e3a6d2e04489 20fd20

  40. [48]

    [Online]

    ARM, Documentation – arm developer . [Online]. Available: https: //developer.arm.com/documentation/101430/r1p2/Functional-descripti on/Memory-Management-Unit/About-the-MMU/AArch64-behavior

  41. [49]

    A unified blocking analysis for parallel tasks with spin locks under global fixed priority scheduling,

    X. Jiang, Z. Chen, M. Yang, N. Guan, Y . Tang, and Y . Wang, “A unified blocking analysis for parallel tasks with spin locks under global fixed priority scheduling,” IEEE Transactions on Computers , vol. 72, no. 1, pp. 15–28, 2023

    2023

  42. [50]

    Linux patch isolcpus: Affine unbound kernel threads to housekeeping cpus

    M. Tosatti, “Linux patch isolcpus: Affine unbound kernel threads to housekeeping cpus.” [Online]. Available: https://git.kernel.org/pub/scm /linux/kernel/git/torvalds/linux.git/commit/?id=9cc5b8656892a72438ee 7deb5e80f5be47643b8b

  43. [51]

    [Online]

    HiSilicon, TaiShan v110 - Microarchitectures - HiSilicon . [Online]. Available: https://en.wikichip.org/wiki/hisilicon/microarchitectures/tais han v110

  44. [52]

    Speck: a kernel for scalable predictability,

    Q. Wang, Y . Ren, M. Scaperoth, and G. Parmer, “Speck: a kernel for scalable predictability,” in 21st IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS’15) , 2015

    2015

  45. [53]

    Kennedy, A survey of data flow analysis techniques

    K. Kennedy, A survey of data flow analysis techniques . IBM Thomas J. Watson Research Division, 1979

    1979

  46. [54]

    Flowdroid: precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps,

    S. Arzt, S. Rasthofer, C. Fritz, E. Bodden, A. Bartel, J. Klein, Y . Le Traon, D. Octeau, and P. McDaniel, “Flowdroid: precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps,” in Proceedings of the 35th ACM SIGPLAN Conference on Prog...

    2014

  47. [55]

    DR. CHECKER: A soundy analysis for linux kernel drivers,

    A. Machiry, C. Spensky, J. Corina, N. Stephens, C. Kruegel, and G. Vigna, “DR. CHECKER: A soundy analysis for linux kernel drivers,” in 26th USENIX Security Symposium (USENIX Security’17) , 2017

    2017

  48. [56]

    Taintpipe: pipelined symbolic taint analysis,

    J. Ming, D. Wu, G. Xiao, J. Wang, and P. Liu, “Taintpipe: pipelined symbolic taint analysis,” in Proceedings of the 24th USENIX Conference on Security Symposium, (USENIX Security’15) , 2015

    2015

  49. [57]

    De- mystifying the real-time linux scheduling latency,

    D. B. de Oliveira, D. Casini, R. S. de Oliveira, and T. Cucinotta, “De- mystifying the real-time linux scheduling latency,” in 32nd Euromicro Conference on Real-Time Systems (ECRTS 2020) . Schloss Dagstuhl- Leibniz-Zentrum f ¨ur Informatik, 2020

    2020

  50. [58]

    sel4: Formal verification of an os kernel,

    G. Klein, K. Elphinstone, G. Heiser, J. Andronick, D. Cock, P. Derrin, D. Elkaduwe, K. Engelhardt, R. Kolanski, M. Norrish et al. , “sel4: Formal verification of an os kernel,” in Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles (SOSP’09) , 2009

    2009

  51. [59]

    Certikos: an extensible architecture for building certified concurrent os kernels,

    R. Gu, Z. Shao, H. Chen, X. Wu, J. Kim, V . Sj ¨oberg, and D. Costanzo, “Certikos: an extensible architecture for building certified concurrent os kernels,” in Proceedings of the 12th USENIX Conference on Operating Systems Design and Implementation (OSDI’16) , 2016

    2016

  52. [60]

    Noninterference specifications for secure systems,

    L. Nelson, J. Bornholt, A. Krishnamurthy, E. Torlak, and X. Wang, “Noninterference specifications for secure systems,” ACM SIGOPS Operating Systems Review , vol. 54, no. 1, pp. 31–39, 2020

    2020

  53. [61]

    Development statistics for the 6.1 kernel (and beyond)

    J. Corbet, “Development statistics for the 6.1 kernel (and beyond).” [Online]. Available: https://lwn.net/Articles/915435/

  54. [62]

    Linux patch revert

    T. Gleixner, “Linux patch revert ”lib: Restrict cpumask local spread to houskeeping cpus”.” [Online]. Available: https://git.kernel.org/pub/scm /linux/kernel/git/torvalds/linux.git/commit/?id=2452483d9546de1c540f 330469dc4042ff089731

  55. [63]

    stress-ng, https://wiki.ubuntu.com/Kernel/Reference/stress-n g

    C. King, “stress-ng, https://wiki.ubuntu.com/Kernel/Reference/stress-n g.”

  56. [64]

    Cyclictest, https://github.com/jlelli/rt-tests/tree/master/src/c yclictest

    RT-Tests, “Cyclictest, https://github.com/jlelli/rt-tests/tree/master/src/c yclictest.”

  57. [65]

    oslat - os latency detector,

    P. Xu, “oslat - os latency detector,” 2020. [Online]. Available: https://man.archlinux.org/man/oslat.8.en

    2020

  58. [66]

    Oslat, https://github.com/jlelli/rt-tests/tree/master/src/oslat

    RT-Tests, “Oslat, https://github.com/jlelli/rt-tests/tree/master/src/oslat.”

  59. [67]

    The schedulability test collection and toolkit

    B. B. Brandenburg, “The schedulability test collection and toolkit.” [Online]. Available: https://github.com/brandenburg/schedcat

  60. [68]

    Techniques for the synthesis of multiprocessor tasksets,

    P. Emberson, R. Stafford, and R. I. Davis, “Techniques for the synthesis of multiprocessor tasksets,” in Proceedings 1st International Workshop on Analysis Tools and Methodologies for Embedded and Real-time Systems (WATERS’10), 2010

    2010

  61. [69]

    Applying new scheduling theory to static priority pre-emptive scheduling,

    A. N. Audsley, A. Burns, M. Richardson, and K. Tindell, “Applying new scheduling theory to static priority pre-emptive scheduling,” Software Engineering Journal, vol. 8, pp. 284–292, 1993

    1993

  62. [70]

    Spin-based reader-writer syn- chronization for multiprocessor real-time systems,

    B. B. Brandenburg and J. H. Anderson, “Spin-based reader-writer syn- chronization for multiprocessor real-time systems,” Real-Time Systems, vol. 46, no. 1, pp. 25–87, 2010

    2010

  63. [71]

    On spin locks in AUTOSAR: Blocking analysis of fifo, unordered, and priority-ordered spin locks,

    A. Wieder and B. B. Brandenburg, “On spin locks in AUTOSAR: Blocking analysis of fifo, unordered, and priority-ordered spin locks,” in 2013 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS’13), 2013

    2013

  64. [72]

    Reader-writer synchronization for shared-memory multiprocessor real- time systems,

    “Reader-writer synchronization for shared-memory multiprocessor real- time systems,” in Proceedings of the 2009 21st Euromicro Conference on Real-Time Systems (ECRTS’09) , 2009

    2009

  65. [73]

    core flight system (cfs) starter kit

    OpenSatKit, “core flight system (cfs) starter kit.” [Online]. Available: https://opensatkit.github.io/

  66. [74]

    Modeling and analysis of inter-process communication delay in ros 2,

    X. Luo, X. Jiang, N. Guan, H. Liang, S. Liu, and W. Yi, “Modeling and analysis of inter-process communication delay in ros 2,” in 2023 IEEE Real-Time Systems Symposium (RTSS’23) , 2023

    2023

  67. [75]

    Seam: An optimal message synchronizer in ros with well-bounded time disparity,

    J. Sun, T. Wang, Y . Li, N. Guan, Z. Guo, and G. Tan, “Seam: An optimal message synchronizer in ros with well-bounded time disparity,” in 2023 IEEE Real-Time Systems Symposium (RTSS’23) , 2023

    2023

  68. [76]

    Worst- case latency analysis of message synchronization in ros,

    R. Li, X. Jiang, Z. Dong, J.-M. Wu, C. J. Xue, and N. Guan, “Worst- case latency analysis of message synchronization in ros,” in 2023 IEEE Real-Time Systems Symposium (RTSS) , 2023

    2023

  69. [77]

    Irobot-ros/ros2-performance: Framework to evaluate peformance of ros 2

    Irobot-Ros, “Irobot-ros/ros2-performance: Framework to evaluate peformance of ros 2.” [Online]. Available: https://github.com/iro bot-ros/ros2-performance

Pith tools

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