Pith. sign in

REVIEW 4 major objections 4 minor 46 references

SuperPass claims that on Android, most priority-inversion blocking of latency-critical threads comes from scheduler runqueue delays rather than critical sections, and that a fast-track scheduler plus a bounded lock-holder detector can cut t

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-01 15:59 UTC pith:OQV2JAO2

load-bearing objection Genuine first measurement of priority inversion on Android with a plausible kernel fix, but the offline lock fingerprint that gates the headline numbers is unvalidated. the 4 major comments →

arxiv 2607.18097 v2 pith:OQV2JAO2 submitted 2026-07-20 cs.OS

SuperPass: Fast-Tracking Blocking Threads to Mitigate Priority Inversion on Mobile Devices

Lei Li , Yu Liang , Riwei Pan , Youcheng Sun , Nan Guan , Tei-Wei Kuo , Chun Jason Xue This is my paper
classification cs.OS
keywords priority inversionAndroid schedulingCFSscheduler fast tracklock holder identificationUI responsivenessjanky framesrwsem
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

Priority inversion—a high-priority thread waiting on a low-priority one—is a known real-time systems problem, but this paper argues it is frequent and severe on Android, where UI threads can be blocked for up to 210 ms and drop frames. The paper's central claim is that most of that blocking time is not the low-priority thread's lock-holding critical section but the time it spends waiting in the scheduler runqueue after waking. From that, SuperPass fast-tracks the specific low-priority threads that block latency-critical threads by resetting their scheduling metric so they jump to the head of the runqueue, with safeguards capping how many threads and for how long. On a Google Pixel 8 with 16 apps, the authors report a 72.0% reduction in 99.9th-percentile UI blocking duration, a 47.7% reduction in blocking count, 29.2% fewer janky frames, and 0.74% system-wide CPU overhead. If these measurements hold, the paper shows that a small scheduler change, not a full real-time protocol, can handle priority inversion on mobile devices.

Core claim

On Android, priority inversions are frequent and dominated by scheduler-induced runnable delays of low-priority blocking threads, not by critical-section latency; therefore SuperPass identifies low-priority threads that block a latency-critical thread and gives them immediate CPU access via a scheduler fast track that manipulates the CFS runqueue ordering key, using a bounded lock-holder detector that covers most concurrent-reader cases and an offline sleep-fingerprint module to find the contended locks without per-lock instrumentation. The paper reports that this reduces the 99.9th-percentile UI-thread blocking duration by 72.0% on average across 16 apps, reduces blocking count by 47.7%, cu

What carries the argument

The carrying mechanism is the scheduler fast track: a per-thread flag marks a blocking thread, and on enqueue the kernel resets its vruntime to place it at the head of the CFS runqueue, with protection from involuntary preemption until the lock releases or a deadline-aligned lease (8.3–16.7 ms) expires. This is paired with a lock-level detector that labels only holders—writers via the owner field and up to NCPU−1 readers via a bounded list—and bypasses queued waiters by putting the latency-critical thread at the head of the wait queue. An offline module records a single kernel stack symbol on the shared __schedule() sleep path to identify which lock APIs are responsible, avoiding per-lock in

Load-bearing premise

The load-bearing premise is that the single kernel-call-stack entry recorded at a fixed depth when a thread falls asleep identifies the exact lock that blocked the latency-critical thread; if that fingerprint sometimes points to the wrong lock, SuperPass will accelerate the wrong threads and the measured 72% reduction would not generalize. The paper does not report the fingerprint's false-positive or false-negative rates, nor sensitivity to the chosen stack depth, and it stat

What would settle it

A controlled experiment that records sleep fingerprints for known contended locks (e.g., rwsem, mutex, binder call paths) at varying stack depths and computes precision and recall against the ground-truth lock. If a sizable fraction of fingerprints do not uniquely identify the blocking primitive, or if the chosen stack depth changes the mapping, the core mechanism loses its lock identification and the reported reductions would not transfer. Alternatively, run the same 16-app, one-minute workload on a kernel with a different sleep path without re-deriving the lock set and check whether the 72%

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • If SuperPass is right, Android vendors can reduce UI-thread priority-inversion stalls with a small kernel patch rather than per-lock instrumentation or real-time promotion.
  • SuperPass raises the P99.9 runnable delay of non-blocking threads by only 4.7% on average, versus 32.6% for priority inheritance and 13.7% for real-time UI promotion, so its safeguards preserve fairness much better.
  • Because 98% of priority inversions involve fewer than 8 concurrent readers, a bounded holder list suffices for responsiveness on current mobile hardware; the paper says the approach extends to other latency-critical threads such as input dispatch, sensor processing, and camera pipeline control.
  • The fast-track idea is scheduler-agnostic: on Linux EEVDF it can be expressed by adjusting a labeled thread's eligibility time and virtual deadline, so the mitigation is not tied to CFS.
  • Under heavy background contention (6 of 9 cores occupied by busy loops), SuperPass still reduces blocking duration and janky frames while keeping non-blocking thread delays within 3.6% of baseline.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • A reader could test how sensitive the 72% reduction is to the offline lock-identification fingerprint: measuring precision and recall against known contended locks at varying stack depths would show whether the single-symbol fingerprint is unique enough to generalize beyond the tested kernel and app set.
  • The paper's own limitation section notes SuperPass shortens only scheduler-induced runnable delays; workloads where lock holders sleep for I/O inside their critical sections would see less benefit, suggesting a combination with lock redesign (like read-copy-update) rather than a replacement.
  • Because the paper scopes to one latency-critical thread, an open extension is arbitration when multiple latency-critical threads (e.g., UI plus camera pipeline) block on the same lock; the label-propagation logic would need a policy for sharing the fast track among them.
  • The 1000x gap between runnable delay and critical-section latency, if it holds generally, implies that optimizing lock implementations alone will not fix Android jank; scheduler-level fast-tracking is the more direct lever.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 4 minor

Summary. The paper studies priority inversion on Android, focusing on the foreground UI thread as a latency-critical case. It reports that such inversions are frequent and can reach hundreds of milliseconds, and argues that the dominant component is scheduler-induced runnable delay of low-priority lock holders rather than critical-section time. Based on this, the paper proposes SuperPass, a kernel mechanism combining a scheduler fast track that gives immediate CPU access to labeled blocking threads, a lock-level detector that labels holders of contended locks, and an offline module that identifies relevant locks from a single stack symbol captured on the shared __schedule() sleep path. The implementation is evaluated on a Google Pixel 8 with 16 apps, reporting a 72.0% reduction in P99.9 blocking duration, a 47.7% reduction in blocking count, a 29.2% reduction in janky frames, and 0.74% CPU overhead, with comparisons against priority inheritance, real-time UI promotion, and Proxy Execution.

Significance. If the reported results hold, the paper makes a useful contribution to general-purpose OS scheduling: it provides quantitative evidence that priority inversion on Android is dominated by runnable delays, and it demonstrates a low-overhead mitigation that goes beyond classic priority inheritance. The strengths of the paper include a real kernel implementation, direct kernel instrumentation for blocking durations, evaluation across many apps and background workloads, a performance breakdown of design components, and explicit overhead measurements. The reported reductions are large and the mechanism is clearly described. However, the central empirical claim depends on an unvalidated offline lock-identification step, and the user-experience metric is defined in a way that may overstate the causal effect on janky frames. These issues need to be addressed before the quantitative conclusions can be fully accepted.

major comments (4)
  1. [§4.2.2] The offline lock-identification module is load-bearing but unvalidated. It records a single kernel stack symbol at a chosen depth on the shared __schedule() sleep path and uses the aggregated symbols to define the UI-blocking lock set. The paper does not report false-positive/false-negative rates, sensitivity to the chosen stack depth, or whether this set covers the lock acquisitions that actually drive the P99.9 tail. A misidentified lock set would cause the runtime detector to label and accelerate the wrong threads, so the measured 72.0% P99.9 reduction could be an in-sample artifact. The paper also states that the offline results must be re-derived after kernel/vendor updates, which is in tension with the portability claim. Please provide accuracy and coverage measurements for the fingerprint, and ideally a per-app list of identified locks with corresponding blocking-time coverage.
  2. [§2.1 and §6.1.2] The janky-frame metric is defined as frames that overlap priority-inversion blocking intervals on the UI thread. This creates a mechanical coupling: shortening blocking intervals reduces the number of overlapping frames even if the frame's deadline miss is not actually caused by that blocking. The paper reports a 29.2% reduction in janky frames, but it does not establish that these frames would have completed on time without the priority inversion. Please report total janky frames from framestats (not only those overlapping inversion intervals) and, if possible, a causal analysis such as comparing frame timestamps against lock-blocking timestamps.
  3. [§5.2 and §6.3] The comparison with Proxy Execution (PE) is conducted on Cuttlefish, a virtual device, while the main results and the PI/RT-UI comparisons are on the Pixel 8. The paper acknowledges this and lists several differences (no DVFS/thermal limits, no OEM/background services, virtual display pipeline). Those differences can materially change both the frequency of priority inversions and the relative benefit of SuperPass. The claim that SuperPass outperforms PE by 2.61x and 3.64x should be stated as Cuttlefish-specific, or PE should be ported to the physical device. At minimum, report PE results on the same Pixel 8 workload used for other baselines if porting is feasible.
  4. [§5.3 and §6.1.1] The headline P99.9 blocking durations are reported as a single average over 10 one-minute runs, without confidence intervals or per-app dispersion. Given the heavy-tailed nature of the data (e.g., Alipay reaching 210 ms in one run), a few tail events could drive the average. Please provide per-app confidence intervals for P99.9, or per-run distributions, to show that the 72.0% reduction is stable. In addition, several design parameters (reader cap, T_budget, cool-down, stack depth) appear to be informed by the same workload data; a sensitivity analysis would strengthen the claim that the results are not tuned to these specific apps.
minor comments (4)
  1. [Throughout] Typos: 'faireness' (title of §6.1.3), 'exettion' in reference [23], 'mitivation' in reference [11]. Please proofread.
  2. [§4.2.1] Algorithm 1's 'Curr has lower priority than lock_holder' check is described, but the pseudocode does not show how priority ordering is computed for shared-lock readers. Clarify whether the comparison uses the effective priority or the raw nice value, and how it handles multiple readers with different priorities.
  3. [§6.1.1 and Figure 9] Figures 9a and 9b do not show error bars for P99.9 blocking duration, although error bars are shown for the count metric. Adding them would make the variability visible.
  4. [§4.2.2] The sentence 'The same contended lock operations continue to pass through the same scheduler sleep point and produce the same fingerprints' is a strong assumption; it may deserve a reference or a brief mechanism-level justification beyond the current text.

Circularity Check

0 steps flagged

No significant circularity; headline results are empirical measurements and the design choices, while workload-informed, do not entail the measured outcomes.

full rationale

The paper's central claims (72.0% P99.9 blocking-duration reduction, 47.7% blocking-count reduction, 29.2% janky-frame reduction, 0.74% overhead) are empirical results measured after implementing SuperPass on a Google Pixel 8. They are not derived from the paper's input distributions or from any fitted parameter renamed as a prediction. The offline lock-identification module does select a set of locks from profiling traces, and the runtime detector then fast-tracks holders of those locks; this creates a reasonable concern about in-sample tuning and generalizability, especially because the paper reports no fingerprint accuracy or sensitivity analysis and states the offline analysis must be re-run after kernel/vendor updates. However, that is a robustness/overfitting concern, not construction-level circularity: the evaluation could have failed, and the measured reductions are not mathematically forced by how the lock set was built. No load-bearing self-citation is used, and no cited theorem or prior result is invoked to make the design choice circular. The paper is self-contained against external measurements and does not reduce any claimed result to its own inputs by definition.

Axiom & Free-Parameter Ledger

5 free parameters · 6 axioms · 0 invented entities

The central claims rest on several empirically motivated domain assumptions rather than mathematical axioms. The two load-bearing heuristics are the bounded reader cap (validated only by the 98% distribution) and the sleep-fingerprint lock identification (not validated). No new physical or conceptual entities are introduced; fast track and labels are modifications to existing kernel structures.

free parameters (5)
  • reader_holder_cap = 8 (N_CPU - 1)
    Bounded holder list in each rwsem (8 entries, 64B) chosen because 98% of measured priority inversions involve fewer than 8 concurrent readers (Figure 7). It trades tail coverage for low overhead.
  • acceleration_lease_T_budget = 8.3-16.7 ms (frame interval)
    Labels are revoked at least once per latency budget; set to the frame interval for the UI-thread instantiation (§4.1.2).
  • relabel_cooldown = 1 ms
    Chosen as a small fraction of the frame budget to prevent immediate repeated re-acceleration while allowing re-labeling within the same frame (§4.1.2).
  • blocking_count_threshold = 100 µs
    Threshold used to count non-negligible priority-inversion blockings and to compute the janky-frame correlation; excludes trivial events (§5.3).
  • sleep_fingerprint_stack_depth = unspecified (stackNum)
    One kernel stack frame at a chosen depth is recorded to fingerprint the sleep path; sensitivity to this depth is not analyzed (§4.2.2).
axioms (6)
  • domain assumption Runnable delay, not critical-section time, dominates priority-inversion blocking duration on Android CFS (1000x gap at P99.9).
    Design premise of the fast track; measured on the 16-app workload (§3.1, Figure 6).
  • domain assumption Long priority-inversion blockings on Android come from sleepable locks (rwsem), identifiable via the scheduler sleep path.
    Spinlock contention is measured at P99.99 660us while rwsem reaches 210ms; this motivates the sleep-fingerprint approach (§4.2.2).
  • domain assumption Tracking a bounded set of reader holders (<= N_CPU-1) is sufficient for responsiveness on mobile devices.
    Based on the observed distribution (98% of inversions have <=8 readers, Figure 7); the paper explicitly acknowledges weaker applicability on many-core platforms (§3.2).
  • domain assumption Resetting a labeled thread's vruntime and suppressing involuntary preemption does not cause unbounded starvation or harm other threads within the safeguards.
    No formal proof; fairness is evaluated empirically (P99.9 runnable delay of non-blocking threads increases only 4.7% on average) (§4.1.2, §6.1.3).
  • domain assumption The foreground UI thread is a representative latency-critical thread; results generalize to other latency-critical threads.
    The paper evaluates only the UI thread; generalization to input dispatch, camera pipeline, etc. is argued but not measured (§1, §4.3).
  • domain assumption A single kernel symbol at a chosen stack depth on the __schedule() sleep path uniquely identifies the blocking lock.
    Unvalidated heuristic; the paper states offline results must be re-derived after kernel or vendor updates (§4.2.2).

pith-pipeline@v1.3.0-alltime-deepseek · 19664 in / 15565 out tokens · 148330 ms · 2026-08-01T15:59:45.112970+00:00 · methodology

0 comments
read the original abstract

Priority inversion occurs when a high-priority thread is delayed by a lower-priority one. Although well studied in real-time systems, its impact in general-purpose OSes (e.g., Android) remains underexplored. On Android, we find that priority inversions happen frequently and can delay latency-critical threads, degrading user experience. For example, the foreground app's UI thread is frequently blocked by low-priority threads, with blocking durations of up to 210 ms, enough to cause dropped frames. Existing solutions designed for real-time systems fail to eliminate long priority-inversion blockings on latency-critical threads and may introduce high overhead on Android. To solve this problem, we uncover two insights on Android: 1) long blockings are mainly due to the accumulated CPU waiting time of low-priority blocking threads rather than their critical-section latency; and 2) although latency-critical threads can be blocked by many concurrent readers, tracking a limited number of them is sufficient to achieve good responsiveness with low overhead in most cases. Guided by these insights, we propose SuperPass, a lightweight kernel mechanism that mitigates priority inversion by fast-track scheduling of low-priority threads blocking latency-critical threads. It introduces a scheduler fast track that grants immediate CPU access to threads blocking latency-critical threads, and employs a lock-level detector that effectively identifies most such blocking threads. We evaluate SuperPass on a Google Pixel 8 smartphone. Taking UI thread as a case study, SuperPass decreases the 99.9th-percentile blocking duration by 72.0% and blocking count by 47.7% on average compared to the default scheduler, and reduces janky frames by 29.2% with a system-wide CPU overhead of only 0.74%. SuperPass also outperforms existing approaches including priority inheritance, real-time UI promotion, and Proxy Execution.

Figures

Figures reproduced from arXiv: 2607.18097 by Chun Jason Xue, Lei Li, Nan Guan, Riwei Pan, Tei-Wei Kuo, Youcheng Sun, Yu Liang.

Figure 1
Figure 1. Figure 1: Priority inversion blockings on latency-critical threads (foreground UI thread as a case study). Priority in￾versions can last long enough to cause frame drops. find that existing real-time solutions fail to eliminate long priority-inversion blockings on latency-critical threads and can incur high overhead on Android for two reasons. First, Android’s scheduler does not guarantee immediate CPU ac￾cess after… view at source ↗
Figure 2
Figure 2. Figure 2: Priority inversions correlate with janky frames. Each point is one run. Points with the same marker and color correspond to the same app. The solid line is a least-squares fit with a 95% bootstrap confidence interval (shaded). Across runs, the correlation is strong (Pearson 𝑟 = 0.79, Spearman 𝜌 = 0.84). for priority inversion: priority inheritance (PI) and priority ceiling protocol (PCP) [22, 26, 41]. PI t… view at source ↗
Figure 3
Figure 3. Figure 3: P99.9 blocking duration of priority inversions on UI threads across 16 apps under Baseline, PI, and RT-UI. The red horizontal line at 8.3 ms marks the per-frame budget at 120 Hz. A block duration exceeding this latency will miss the 120 Hz deadline and result in a dropped frame (i.e., jank). While RT-UI benefits some apps, it degrades others. RT￾UI promotes the UI thread to the real-time class, but it does… view at source ↗
Figure 4
Figure 4. Figure 4: P99.9 CPU waiting time for non-blocking low￾priority threads across 16 apps under Baseline, PI, and RT-UI. In summary, existing approaches fail to consistently elim￾inate long priority-inversion blockings on UI threads and may increase the CPU waiting time of non-blocking threads, thereby impacting fairness. 3 Insights and Analysis In this section, we first breakdown the long priority-inversion blocking du… view at source ↗
Figure 5
Figure 5. Figure 5: Priority-inversion blocking breakdown. SuperPass reduces the runnable delay of low-priority reader holders, and thus shortens the priority-inversion blocking duration of the latency-critical thread [PITH_FULL_IMAGE:figures/full_fig_p005_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Critical-section latency vs. runnable delay across 16 apps. The x-axis uses a logarithmic scale to cover latencies from nanoseconds to seconds. The bold curves are calculated from all results merged across the 16 apps, while the light curves show the per-trace results for individual app. At P99.9, runnable delay is 1000× of critical-section latency. Second, one blocking thread can incur multiple runnable d… view at source ↗
Figure 8
Figure 8. Figure 8: Design overview of SuperPass. 4.1 Fast-Track Scheduling for Blocking Threads Guided by Insight 1, SuperPass focuses on the dominant contributor to long priority-inversion blockings: scheduler induced runnable delays of blocking threads. SuperPass therefore accelerates blocking threads in the scheduler to cut their runnable delays using a scheduler fast track. However, this path can increase contention and … view at source ↗
Figure 10
Figure 10. Figure 10: suggests that this depends on lock-acquisition in￾tensity. Apps like Alipay produce thousands of lock requests and thus face more priority inversions, while Firefox ac￾quires fewer locks and correspondingly has fewer priority inversions. These results indicate that lock-acquisition in￾tensity is a key factor in an app’s susceptibility to severe priority-inversion blockings on UI thread. Performance Breakd… view at source ↗
Figure 9
Figure 9. Figure 9: Overall performance (UI-thread instantiation). The duration and number of UI-thread priority-inversion block￾ings on Baseline, PI, RT-UI, and SuperPass. inversion blocking, SuperPass achieves a 47.7% reduction relative to Baseline, corresponding to 2.2× fewer blocks than PI and 2.5× fewer than RT-UI. SuperPass reduces the dura￾tion longer than > 100 µs by effectively accelerating blocking threads of UI thr… view at source ↗
Figure 14
Figure 14. Figure 14: Performance under heavy workload. Each row reports, from top to bottom, the P99.9 blocking duration, the number of blocks >100 µs, and the number of janky frames for Alipay and Facebook. The x-axis “𝑘/9” denotes that 𝑘 of the 9 CPU cores are preoccupied by the busy-loop workers. Specifically, We pin 𝑘 ∈ {2, 4, 6} busy-loop workers to distinct cores while running 12 background apps concur￾rently in the bac… view at source ↗
Figure 12
Figure 12. Figure 12: Number of janky frames (normalized to Baseline). In conclusion, these results show that SuperPass have small faireness impact on non-blocking threads, consistent with the safeguards in § 4.1.2. Although strict fairness cannot be guaranteed, SuperPass still outperforms existing methods by respecting smartphone workloads where foreground apps and UI threads are prioritized for user experience. 0 100 200 300… view at source ↗
Figure 13
Figure 13. Figure 13: P99.9 runnable delay of low-priority threads not blocking UI thread across 16 apps. 6.2 Performance under Heavy Workloads To emulate heavy usage, we add a synthetic CPU workload with busy-loop workers pinned to cores. We use this work￾load only in this subsection to evaluate SuperPass under heavier background contention and to verify both its robust￾ness and fairness impact on non-blocking threads. 0 50 1… view at source ↗
Figure 15
Figure 15. Figure 15: P99.9 runnable delay of low-priority threads not blocking UI thread across 16 apps, under heavy background workload with 6 busy-loop workers. 0 5 10 15 20 25 P99.9 Blocking Duration (ms) Baseline Proxy Execution SuperPass 0 20 40 60 80 Number of Priority Inversion Blocking s (>100 μs) Baseline Proxy Execution SuperPass [PITH_FULL_IMAGE:figures/full_fig_p012_15.png] view at source ↗
Figure 16
Figure 16. Figure 16: Comparison with Proxy Execution on Cuttlefish [PITH_FULL_IMAGE:figures/full_fig_p012_16.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

46 extracted references · 1 canonical work pages

  1. [1]

    Ideally we would like to track all the readers that own a rwsem, but the overhead is simply too big. [Online; accessed 20-March-2026]

    2023. kernel/locking/rwsem.c (comment on overhead of track- ing readers).https://git.zx2c4.com/wireguard-linux/tree/kernel/ locking/rwsem.c. Source comment: “Ideally we would like to track all the readers that own a rwsem, but the overhead is simply too big. [Online; accessed 20-March-2026]”

    2023

  2. [2]

    Google Pixel 8.https://en.wikipedia.org/wiki/Pixel_8

    2024. Google Pixel 8.https://en.wikipedia.org/wiki/Pixel_8. [Online; accessed 20-March-2026]

    2024

  3. [3]

    SCHED_DEADLINE Linux Documentation.https://www

    2024. SCHED_DEADLINE Linux Documentation.https://www. kernel.org/doc/Documentation/scheduler/sched-deadline.txt. [On- line; accessed 20-March-2026]

    2024

  4. [4]

    Slow rendering.https://developer.android.com/topic/ performance/vitals/render

    2024. Slow rendering.https://developer.android.com/topic/ performance/vitals/render. [Online; accessed 20-March-2026]

    2024

  5. [5]

    UI jank detection.https://developer.android.com/studio/ profile/jank-detection

    2024. UI jank detection.https://developer.android.com/studio/ profile/jank-detection. [Online; accessed 20-March-2026]

    2024

  6. [6]

    Android dumpsys.https://developer.android.com/tools/ dumpsys

    2025. Android dumpsys.https://developer.android.com/tools/ dumpsys. [Online; accessed 20-March-2026]

    2025

  7. [7]

    Cuttlefish virtual Android devices.https://source.android

    2025. Cuttlefish virtual Android devices.https://source.android. com/docs/devices/cuttlefish. [Online; accessed 20-March-2026]

    2025

  8. [8]

    Learn about rendering in game loops.https://developer

    2025. Learn about rendering in game loops.https://developer. android.com/games/develop/gameloops. [Online; accessed 20- March-2026]

    2025

  9. [9]

    Proxy Execution Github.https://github.com/johnstultz-work/ linux-dev/tree/proxy-exec-v6-6.6

    2025. Proxy Execution Github.https://github.com/johnstultz-work/ linux-dev/tree/proxy-exec-v6-6.6. [Online; accessed 20-March- 2026]

    2025

  10. [10]

    SurfaceView and GLSurfaceView.https://source.android

    2025. SurfaceView and GLSurfaceView.https://source.android. com/docs/core/graphics/arch-sv-glsv. [Online; accessed 20-March- 2026]

    2025

  11. [11]

    Thermal mitivation.https://source.android.com/docs/core/ power/thermal-mitigation

    2025. Thermal mitivation.https://source.android.com/docs/core/ power/thermal-mitigation. [Online; accessed 20-March-2026]

    2025

  12. [12]

    EEVDF Scheduler

    2026. EEVDF Scheduler. The Linux Kernel Documentation.https: //docs.kernel.org/scheduler/sched-eevdf.html[Online; accessed 20-March-2026]

    2026

  13. [13]

    Luca Abeni and Giorgio Buttazzo. 1998. Integrating Multimedia Applications in Hard Real-Time Systems. InProceedings of the IEEE Real-Time Systems Symposium (RTSS)

    1998

  14. [14]

    2013.big.LITTLE Technology: The Future of Mobile

    ARM Ltd. 2013.big.LITTLE Technology: The Future of Mobile. Technical Report. ARM Whitepaper.https://developer.arm.com/- /media/Files/pdf/white-paper/big-little-technology-the-future- of-mobile.pdf

    2013

  15. [15]

    Babaoglu, K

    O. Babaoglu, K. Marzullo, and F. Schneider. 1993.A Formalization of Priority Inversion. Technical Report

    1993

  16. [16]

    T.P. Baker. 1990. A stack-based resource allocation policy for real- time processes. In1990 Proceedings 11th Real-Time Systems Sympo- sium. 191–200

    1990

  17. [17]

    2020.Scheduling for the Android display pipeline

    Alessio Balsini. 2020.Scheduling for the Android display pipeline. https://lwn.net/Articles/809545/[Online; accessed 20-March-2026]

    2020

  18. [18]

    Justinien Bouron, Sebastien Chevalley, Baptiste Lepers, Willy Zwaenepoel, Redha Gouicem, Julia Lawall, Gilles Muller, and Julien Sopena. 2018. The Battle of the Schedulers: FreeBSD ULE vs. Linux CFS. In2018 USENIX Annual Technical Conference (USENIX ATC 18). USENIX Association, Boston, MA, 85–96

    2018

  19. [19]

    Brandenburg and James H

    Björn B. Brandenburg and James H. Anderson. 2010. Spin-based reader-writer synchronization for multiprocessor real-time systems. 46, 1 (Sept. 2010), 25–87. doi:10.1007/s11241-010-9097-2

    work page doi:10.1007/s11241-010-9097-2 2010

  20. [20]

    Andreu Carminati, Rômulo Oliveira, Fernando Luís, and Friedrich

  21. [21]

    Zewei Chen, Hang Lei, Maolin Yang, Yong Liao, and Lei Qiao. 2021. A Hierarchical Hybrid Locking Protocol for Parallel Real-Time Tasks.ACM Trans. Embed. Comput. Syst.20, 5s, Article 86 (sep 2021), 22 pages

    2021

  22. [22]

    Albert MK Cheng and James Ras. 2007. The implementation of the priority ceiling protocol in Ada-2005.ACM SIGAda Ada Letters27, 1 (2007), 24–39

    2007

  23. [23]

    Jonathan Corbet. 2023. Addressing priority inversion with proxy exettion. LWN.net.https://lwn.net/Articles/934114/[Online; accessed 20-March-2026]

    2023

  24. [24]

    Jonathan Corbet. 2023. What remains to be done for proxy execu- tion. LWN.net.https://lwn.net/Articles/953438/[Online; accessed 20-March-2026]

    2023

  25. [25]

    Dave Dice and Alex Kogan. 2019. BRAVO—Biased Locking for Reader-Writer Locks. In2019 USENIX Annual Technical Conference (USENIX ATC 19). USENIX Association, Renton, WA, 315–328

    2019

  26. [26]

    John B Goodenough and Lui Sha. 1988. The priority ceiling protocol: A method for minimizing the blocking of high priority Ada tasks. ACM SIGAda Ada Letters8, 7 (1988), 20–31. 13

    1988

  27. [27]

    Google. 2024. Mobile App Usage & Download Statistics.https: //buildfire.com/app-statistics/. [Online; accessed 20-March-2026]

    2024

  28. [28]

    Holman and J.H

    P. Holman and J.H. Anderson. 2002. Object sharing in Pfair- scheduled multiprocessor systems. InProceedings 14th Euromicro Conference on Real-Time Systems. Euromicro RTS 2002. 111–120

    2002

  29. [29]

    Takashi Hoshino and Kenjiro Taura. 2025. Fairer and More Scalable Reader-Writer Locks by Optimizing Queue Management. InPro- ceedings of the 30th ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Programming(Las Vegas, NV, USA)(PPoPP ’25). Association for Computing Machinery, New York, NY, USA, 115–127

    2025

  30. [30]

    Sanidhya Kashyap, Irina Calciu, Xiaohe Cheng, Changwoo Min, and Taesoo Kim. 2019. Scalable and practical locking with shuffling. InProceedings of the 27th ACM Symposium on Operating Systems Principles(Huntsville, Ontario, Canada)(SOSP ’19). Association for Computing Machinery, New York, NY, USA, 586–599. doi:10.1145/ 3341301.3359629

    arXiv 2019

  31. [31]

    Chan-Kyung Kim, Eu teum Choi, Mingyun Han, Seongjin Lee, and Jaeho Kim. 2022. Performance Analysis of RCU-Style Non-Blocking Synchronization Mechanisms on a Manycore-Based Operating Sys- tem.Applied Sciences(2022)

    2022

  32. [32]

    Yu Liang, Jinheng Li, Rachata Ausavarungnirun, Riwei Pan, Liang Shi, Tei-Wei Kuo, and Chun Jason Xue. 2020. Acclaim: Adaptive Memory Reclaim to Improve User Experience in Android Systems. In2020 USENIX Annual Technical Conference (USENIX ATC 20). USENIX Association, 897–910

    2020

  33. [33]

    Giuseppe Lipari and Enrico Bini. 2003. A Framework for Hier- archical Scheduling. InProceedings of the IEEE Real-Time Systems Symposium (RTSS)

    2003

  34. [34]

    Shengzhong Liu, Shuochao Yao, Xinzhe Fu, Rohan Tabish, Simon Yu, Ayoosh Bansal, Heechul Yun, Lui Sha, and Tarek Abdelzaher

  35. [35]

    Locke, L

    D. Locke, L. Sha, R. Rajikumar, J. Lehoczky, and G. Burns. 1988. Priority inversion and its control: An experimental investigation. InProceedings of the Second International Workshop on Real-Time Ada Issues(Moretonhampstead, Devon, England)(IRTA W ’88). As- sociation for Computing Machinery, New York, NY, USA, 39–42

    1988

  36. [36]

    Jean-Pierre Lozi, Baptiste Lepers, Justin Funston, Fabien Gaud, Vivien Quéma, and Alexandra Fedorova. 2016. The Linux scheduler: a decade of wasted cores. InProceedings of the Eleventh European Conference on Computer Systems(London, United Kingdom)(Eu- roSys ’16). Association for Computing Machinery, New York, NY, USA, Article 1, 16 pages

    2016

  37. [37]

    McKenney

    Paul E. McKenney. 2024. The RCU API, 2024 edition.LWN.net(Sept. 2024).https://lwn.net/Articles/988638/

    2024

  38. [38]

    McKenney, Joel Fernandes, Silas Boyd-Wickizer, and Jonathan Walpole

    Paul E. McKenney, Joel Fernandes, Silas Boyd-Wickizer, and Jonathan Walpole. 2020. RCU Usage In the Linux Kernel: Eigh- teen Years Later. 54, 1 (Aug. 2020), 47–63

    2020

  39. [39]

    Sarvesh Pandey and Udai Shanker. 2020. Transaction scheduling protocols for controlling priority inversion: A review.Computer Science Review35 (2020), 100215

    2020

  40. [40]

    Rajkumar

    R. Rajkumar. 1990. Real-time synchronization protocols for shared memory multiprocessors. InProceedings.,10th International Confer- ence on Distributed Computing Systems. 116–123

    1990

  41. [41]

    L. Sha, R. Rajkumar, and J.P. Lehoczky. 1990. Priority inheritance protocols: an approach to real-time synchronization.IEEE Trans. Comput.39, 9 (1990), 1175–1185

    1990

  42. [42]

    Silambarasan and M RamanathaVenkatesan

    D. Silambarasan and M RamanathaVenkatesan. 2016. Handling of Priority Inversion Problem in RT-Linux using Priority Ceiling Protocol

    2016

  43. [43]

    John Stultz. 2023. [PATCH v3 00/14] Generalized Priority Inher- itance and Proxy Execution. Linux Kernel Mailing List (LKML). https://lkml.org/lkml/2023/4/11/17[Online; accessed 20-March- 2026]

    2023

  44. [44]

    Takada, and K

    Cai-Dong Wang, H. Takada, and K. Sakamura. 1996. Priority in- heritance spin locks for multiprocessor real-time systems. InPro- ceedings Second International Symposium on Parallel Architectures, Algorithms, and Networks (I-SPAN’96). 70–76. 14

    1996

  45. [2012]

    Implementation and Evaluation of the Synchronization Pro- tocol Immediate Priority Ceiling in PREEMPT-RT Linux.Journal of Software7 (03 2012)

    2012

  46. [2020]

    In2020 IEEE Real-Time Systems Symposium (RTSS)

    On removing algorithmic priority inversion from mission- critical machine inference pipelines. In2020 IEEE Real-Time Systems Symposium (RTSS). IEEE, 319–332