Pith. sign in

REVIEW 4 major objections 5 minor 46 references

Locked In, Leaked Out: Measuring Isolation via Kernel Locks

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 ↗ Review JSON

Pith's one-line read The paper argues that isolation between co-located workloads can be measured by the kernel locks they share: common lock acquisitions reveal shared kernel data structures, and their frequency predicts how much the workloads can interfere.

desk verdict A useful first-step map of shared kernel locks across four isolation platforms, but the central claim that lock rate measures isolation is not validated by the experiments. read the letter →

arxiv 2507.21248 v1 pith:JHNFIDRJ submitted 2025-07-28 cs.OS

Anjali , Michael M. Swift This is my paper · ORCID
classification cs.OS
keywords kernellocksisolationmeasurementperformanceinterferenceeBPFtracingshareddatastructurescontainersmicroVMsLinux
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 proposes that the isolation between two co-located workloads can be read from the kernel locks they acquire in common. Because the operating system protects every shared kernel data structure with a lock, the set and frequency of locks shared by two workloads is, the paper argues, a direct measure of the shared state through which they can interfere. The authors build a tool that traces lock acquisitions dynamically and maps each lock to the kernel object it protects, then use it to compare four isolation platforms over microbenchmarks, serverless functions, and cloud workloads. Their measurements identify the file-system journal and the kernel page allocator as the dominant sources of cross-workload interference, and stress tests show performance degradation that tracks high shared-lock access rates. If the claim holds, lock tracing becomes a cheap, quantitative way to choose isolation platforms and co-schedule tenants.

What carries the argument

The carrying mechanism is LockScope, a two-part tool. Its dynamic tracer extends an eBPF kernel lock monitor to record every lock acquisition with its lock address, name, process, and stack trace; its static analyzer resolves incomplete stack traces to source locations and maps each lock to the kernel object that contains it, using symbol information and an abstract syntax tree. From these traces the paper derives three metrics: the set of shared versus private locks, the cumulative lock access rate, and the distribution of lock rates across kernel subsystems. These shared-lock metrics are what connect synchronization behavior to interference and isolation.

What would settle it

Run the same paired workloads with kernel instrumentation that records not just shared-lock acquisition counts but also actual wait time or contention on each lock, alongside end-to-end performance; if two workloads with high shared-lock counts show near-zero contention and no slowdown while workloads with lower counts show slowdowns, the proxy is refuted. The paper's own stress experiments already admit an alternative explanation because the added trasher process is not shown to acquire the same locks as the workload.

Watch

Extended reading notes

Core claim

The paper's central claim is that synchronization frequency is a usable proxy for interference: workloads that frequently lock the same kernel objects share data and can affect each other, while workloads that rarely share locks are well isolated. Empirically, the paper reports that across all tested workloads and platforms, the page allocator locks on memory zone objects and the locks protecting file-system journaling are the most commonly accessed shared structures, with the journal's per-transaction list lock and state lock recurring across file metadata, serverless, and cloud workloads. It also finds that incidentally shared locks, such as the global inode hash lock, are significant interference points even when workloads operate on different files. On the performance side, shared-lock access rates align with measured degradation: host and container platforms show both higher shared-lock rates and larger slowdowns under stress, while the microVM platform accesses fewer host locks and remains comparatively stable. The paper's stated conclusion is that object-level sharing through kernel locks is a measurable, workload- and platform-dependent component of isolation.

Load-bearing premise

The load-bearing premise is that the frequency of shared lock acquisitions, rather than actual lock contention, is a valid proxy for interference: two workloads can acquire the same kernel lock at different times and never wait on each other, so lock counts may overstate the interference they actually cause.

Editorial extensions

If this is right

  • Shared-lock access rates can be turned into a quantitative isolation score that cloud schedulers use to co-locate workloads with few common kernel objects.
  • Kernel developers have a concrete target list: splitting or per-tenant partitioning the file-system journal and the page allocator would remove the two most common interference channels.
  • The same workload shows a different kernel-object footprint on each platform, so isolation strength is not a single property of a platform but a workload-dependent match.
  • Stateless serverless functions do not need crash-consistent journaling, so disabling or bypassing the journal could eliminate a major shared-lock source for them.
  • Fine-grained locking alone does not guarantee isolation, since incidentally shared structures like the global inode hash lock still create interference under load.

Reading between the lines

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

  • Extension: weighting lock traces by actual wait or contention time, not just acquisition count, should produce a sharper isolation metric and could separate harmless shared access from real interference.
  • Extension: the same synchronization-as-sharing logic could be applied to user-space and language-runtime locks, extending the technique to in-process multi-tenancy where kernel traces see little.
  • Extension: covering RCU, atomics, and other lockless synchronization would close the acknowledged blind spot, since interference through lockless shared state is invisible to a lock-only trace.
  • Extension: a testable deployment would run the tracer on production multi-tenant traces and check whether the predicted interference ranking matches observed latency or throughput loss.
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

4 major / 5 minor

Summary. The paper proposes LockScope, a tool combining an eBPF-based dynamic tracer with a clangd-based static analyzer, to record kernel lock acquisitions and map them to protecting kernel objects. Using two co-located instances of each workload on host Linux, runc, gVisor/runsc, and Firecracker, the authors count locks acquired in common and their acquisition rates, interpreting these as a measure of sharing and hence of interference/isolation. The paper also runs stress tests with a 'trasher' to link shared locking to performance degradation and concludes that the filesystem journal and page allocator are the dominant sources of cross-workload interference.

Significance. The contribution is potentially useful: a direct, parameter-free measurement of shared kernel objects across isolation platforms would be a practical aid for scheduling and platform selection, and the comparative dataset (microbenchmarks, serverless, and cloud workloads) is valuable. The static analysis for lock-to-object mapping and the careful filtering of interrupt-context locks are strengths. However, the paper's central claim requires that shared-lock acquisition frequency track actual contention and interference; this equivalence is not established, and the validation experiment does not rule out non-lock interference. If the equivalence can be demonstrated (e.g., via lock wait/contention traces and a traced trasher), the approach would be a meaningful step for the systems community; as it stands, the contribution is a measurement study whose interpretation outruns its evidence.

major comments (4)
  1. [Section 3, Section 5.2, Table 5] The operational metric is the number of shared lock addresses and the cumulative rate of acquisitions of those locks, not synchronization or contention. Two workloads can acquire the same lock at disjoint times and never wait for each other, so acquisition frequency overstates interference; conversely, serialization through atomics, RCU, or cache-line read sharing is invisible to the tracer. The sentence in the abstract and Section 3 that 'by measuring the level of synchronization between workloads, we can measure their ability to interfere' is therefore not supported by the reported metrics. The tracer records hold time but the paper never reports wait time, spin count, or any direct contention event. I would like to see either direct contention measurements (e.g., lock wait times obtained from the same traces) or an explicit empirical validation that shared acquisition rate predicts contention and slowdown.
  2. [Section 5.3, Section 7, Figures 4-6] The validation experiments do not demonstrate that the observed degradation is caused by shared kernel locks. The trasher is described only as stressing kernel resources through frequent system calls (Section 5.3); no trace is shown that the trasher acquires the same locks as the worker, so CPU, cache, DRAM bandwidth, and disk contention remain plausible alternative explanations. The claim in Section 5.1 that the setup 'avoid[s] hardware interference' is asserted but not verified with any performance counter (e.g., LLC misses or memory bandwidth). In addition, the three runs are averaged without reporting variance, making it hard to assess whether the small degradations in Figures 4-6 are significant. Please trace the trasher, show that it contends on the same locks, and report error bars or per-run data.
  3. [Section 7.1.1 vs Table 5] There is an internal inconsistency in the memory stress results. Table 5 reports for runc mem-8KB a shared lock count of 0.33 and a shared lock rate of 0.0016, while fc has the highest shared lock rate for mem-8KB (399) and a count of 2.67. Yet Section 7.1.1 says runc degrades under memory load and fc is not impacted after startup. On the paper's own proxy, runc should be nearly immune to lock-based interference and fc should be the most affected. The mismatch needs to be explained; as written, this undermines the claim in Section 7.4 that 'the level of shared locking relates to the amount of interference.'
  4. [Sections 2 and 3] The paper frames synchronization as the universal identifier of sharing ('operating systems synchronize all access to shared resources'), but LockScope only covers lock primitives, and Section 3 explicitly defers atomics, RCU, and memory barriers. This limitation is acknowledged, but the abstract and conclusions do not carry the caveat. Since lockless mechanisms can still serialize (e.g., refcounts, seqlock readers on the same cache line) and read sharing of cache lines can interfere without any lock acquisition, the central claim as stated is broader than the evidence. The paper should either restrict the claim to lock-based interference or justify why the excluded mechanisms cannot account for the degradations in Section 7.
minor comments (5)
  1. [Section 5.2, Table 5] The 'shared (rate)' column in Table 5 is not defined in the table itself; the distinction between shared lock count and cumulative lock access rate should be stated in the caption.
  2. [Section 7.1.1] The sentence 'However, it does has have a higher execution time...' should read 'it does have a higher execution time...'.
  3. [References] References [33] and [34] are the same paper (Min et al., 'Understanding manycore scalability of file systems') and should be merged to avoid duplication.
  4. [Section 4.2] The paper reports that only about 75% of locks are mapped to objects; a sentence quantifying how the unresolved 25% could affect the subsystem attribution in Figures 2 and 3 would help the reader judge the robustness of those conclusions.
  5. [Section 6.2.1] The sentence 'so frequent writing of file data is surprising may be due to using legacy code in a serverless environment' is missing a word or comma and should be rephrased.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the lock-based isolation metric is directly measured and validated against independent performance experiments, with no fitted parameters or self-citation chain forcing the result.

full rationale

The paper's central claim is that the level of synchronization between workloads indicates their ability to interfere, and hence the degree of isolation. This is an asserted proxy, not a quantity derived from fitted parameters or from the paper's own definitions. The shared-lock counts and access rates in Table 5 are obtained directly from eBPF lock traces and static lock-to-object mapping; there is no free parameter, no normalization constructed from the target outcome, and no 'prediction' that reduces to a fitted value. The only validation step, Section 7, compares measured lock usage with independently measured performance degradation under increasing trasher load; that validation is imperfect (the trasher's own lock acquisitions are not traced, and Table 5's runc mem-8KB rate of 0.0016 with 0.33 shared locks sits awkwardly with the degradation reported in Section 7.1.1, while fc's high 399 rate does not translate into sustained degradation). These are correctness and evidence concerns, not circularity: the lock metric is not defined in terms of the performance outcomes it is used to explain, and no equation in the paper identifies the two. Self-citations are present but not load-bearing: reference [37], which includes an author of this paper, is cited only as an example of adversarial synchronization in the introduction and does not supply the measurement methodology or any uniqueness claim. No ansatz is smuggled in via citation, and no known result is merely renamed. The paper is self-contained as a measurement study whose core metric is observable trace data, so the derivation chain does not reduce to its inputs.

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

No numerical parameters are fitted to data in this paper; the analysis is purely measurement-based, so there are no fitted constants. The load-bearing assumptions are domain-level simplifications about synchronization as a proxy for sharing and about the stress-test attribution. No new physical or conceptual entities are postulated; LockScope is a software tool, not an invented entity in the sense of a new particle or force.

assumptions (5)
  • domain assumption Operating systems synchronize all access to shared resources, so all meaningful interference between workloads passes through OS synchronization.
    Central premise of Section 3; if false, lock traces would miss interference channels.
  • domain assumption Lock-based synchronization is a sufficient proxy for sharing; lockless mechanisms (RCU, atomics, memory barriers) can be ignored for measuring interference.
    Section 3 explicitly restricts the method to locks and calls lockless approaches 'less interference'; this is an acknowledged limitation but a load-bearing simplification.
  • domain assumption The traced lock primitives and three iterations of runs capture representative lock usage for each workload.
    Section 5.2 describes tracing once per lock type and three iterations; representativeness is assumed, not verified.
  • domain assumption The static analyzer's successful mapping of about 75% of locks to objects is unbiased; the unmapped 25% do not change the qualitative conclusions.
    Section 4.2 reports mapping only 75% of unique locks; the potential bias from the unmapped locks is not assessed.
  • domain assumption Performance degradation in the stress tests is caused by shared kernel locks rather than CPU, cache, or DRAM contention.
    Section 7 attributes degradation to lock interference, but no contention time is measured and the trasher's lock set is not examined; hardware interference is assumed away via SMT-off and CAT.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Locked In, Leaked Out: Measuring Isolation via Kernel Locks." pith.science (2026). https://pith.science/paper/JHNFIDRJ

@misc{pith2026250721248,
  author       = {Pith},
  title        = {Pith review of: Locked In, Leaked Out: Measuring Isolation via Kernel Locks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JHNFIDRJ}},
  note         = {Machine review of arXiv:2507.21248}
}
read the original abstract

Isolation is a critical property for shared infrastructure to limit exposure and interference among simultaneous running workloads. Cloud providers use different isolation mechanisms such as full Virtual Machines, microVMs, Linux containers, secure containers, etc., to confine workloads running in a multi-tenant environment. We propose a novel way to understand and measure performance interference and isolation at the system software layer that occurs due to shared access to data structures. We observe that interference takes place through shared structures, such as a kernel-level data structure, and that operating systems must synchronize access to these structures for safety. By measuring the level of synchronization between workloads, we can measure their ability to interfere and thus the amount of isolation the platform provides We demonstrate our method for measuring isolation by measuring the accesses to locks acquired in common across multiple workloads which indicates the amount of sharing through kernel data structures and hence the interference/isolation between two workloads. Furthermore, we identify the isolation properties of different kernel structures under different workloads and find that the file system journal and kernel page allocator are the most common sources of interference.

Figures

Figures reproduced from arXiv: 2507.21248 by the authors.

Figure 1
Figure 1. Overview of LockScope workflow. In the dynamic tracing phase, LockScope collects lock accesses across work￾loads, and the static analysis phase completes the lock-to￾object mapping. accessed by other processes. tasklist_lock isshared and syn￾chronizes access to a resource shared by multiple processes, the list of all tasks. In the example code, it is used to remove a task from the list when the process exits. Finall… view at source ↗
Figure 2
Figure 2. Serverless workloads shared locks access rate across kernel subsystems. mm and fs are highly accessed across platforms. kernel fs net mm arch Kernel Subsystems 10 0 10 1 10 2 10 3 10 4 10 5 Lock Access Rate (log scale) (a) runc. kernel fs net mm arch Kernel Subsystems 10 0 10 1 10 2 10 3 10 4 10 5 Lock Access Rate (log scale) (b) runsc. kernel fs net mm arch Kernel Subsystems 10 1 10 2 10 3 10 4 Lock Access Rate (lo… view at source ↗
Figure 3
Figure 3. Cloud workloads shared lock access rate across kernel subsystems. Most workloads show high usage in mm and fs across platforms. server warmup (tracing is skipped for warmup phase). Feedsim [7] represents the aggregation and ranking work￾loads in recommendation systems. It searches for the max￾imum QPS that the system can achieve while keeping p95 latency to be no greater than 500ms. VideoTranscodeBench [8] is based … view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Memory stress tests for 8KB ( 4a- 4c) and 1MB ( 4d- 4f) allocation sizes for a total memory of 16GB. All but fc show performance degradation over time under load. Note that y-axes do not go to zero. Lower numbers are better. 0 20 40 60 80 Time (minutes) 10000 15000 200…
Figure 5
Figure 5. Figure 5: Filebench stress tests for filesystem metadata operations. Both, host and runc show significant performance degradation for create/close and delete operations. fc performs uniformly under load. Note that y-axes do not go to zero. Higher numbers are better. 8 Interferen…
Figure 6
Figure 6. Figure 6: FunctionBench stress tests. All platforms show some performance degradation under load for most workloads. Note that the Y-axes do not go to zero. Lower numbers are better. by adding layers, similar to ’sentry’ in gVisor, to segregate highly shared data structures. 9 R…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

46 extracted references · 45 canonical work pages

  1. [1]

    https://cscope.sourceforge.net/

    cscope, 2012. https://cscope.sourceforge.net/

    work page 2012

  2. [2]

    https://github.com/iovisor/bcc/blob/master/ docs/reference_guide.md#12-bpf_get_ns_current_pid_tgid

    bcc reference guide, 2024. https://github.com/iovisor/bcc/blob/master/ docs/reference_guide.md#12-bpf_get_ns_current_pid_tgid

    work page 2024

  3. [3]

    https://github.com/google/gvisor/tree/master/pkg/ sentry/mm

    gvisor mm, 2024. https://github.com/google/gvisor/tree/master/pkg/ sentry/mm

    work page 2024

  4. [4]

    https://microsoft.github.io/language- server-protocol/

    Language server protocol, 2024. https://microsoft.github.io/language- server-protocol/

    work page 2024

  5. [5]

    https://www

    Datacenter benchmarking with cloudsuite 4.0, 2025. https://www. cloudsuite.ch/

    work page 2025

  6. [6]

    https://github.com/facebookresearch/DCPerf

    Dcperf, 2025. https://github.com/facebookresearch/DCPerf

    work page 2025

  7. [7]

    https://github.com/facebookresearch/DCPerf/blob/v1

    Feedsim, 2025. https://github.com/facebookresearch/DCPerf/blob/v1. 0/packages/feedsim/README.md

    work page 2025

  8. [8]

    https://github.com/facebookresearch/DCPerf/blob/v0.2

    Ffmpeg, 2025. https://github.com/facebookresearch/DCPerf/blob/v0.2. 0/packages/video_transcode_bench/README.md/

    work page 2025

Show all 46 references
  1. [9]

    https://gvisor.dev/docs/architecture_guide/ platforms/

    Platform guide, 2025. https://gvisor.dev/docs/architecture_guide/ platforms/

    2025

  2. [10]

    Azab, Peng Ning, and Xiaolan Zhang

    Ahmed M. Azab, Peng Ning, and Xiaolan Zhang. Sice: a hardware- level strongly isolated computing environment for x86 multi-core platforms. In Proceedings of the 18th ACM Conference on Computer and Communications Security, CCS ’11, page 375–388, New York, NY, USA,

  3. [11]

    The multikernel: a new os architecture for scalable multicore systems

    Andrew Baumann, Paul Barham, Pierre-Evariste Dagand, Tim Harris, Rebecca Isaacs, Simon Peter, Timothy Roscoe, Adrian Schüpbach, and Akhilesh Singhania. The multikernel: a new os architecture for scalable multicore systems. In Proceedings of the ACM SIGOPS 22nd Symposium on Ope...

    2009

  4. [12]

    An introduction to lockless algorithms, 2023

    Paolo Bonzini. An introduction to lockless algorithms, 2023. https: //lwn.net/Articles/844224/

    2023

  5. [13]

    Container isolation gone wrong

    Gianluca Borello. Container isolation gone wrong. https://sysdig.com/ blog/container-isolation-gone-wrong/ , 2017

    2017

  6. [14]

    Martínez

    Shuang Chen, Christina Delimitrou, and José F. Martínez. Parties: Qos-aware resource partitioning for multiple interactive services. In Proceedings of the Twenty-Fourth International Conference on Archi- tectural Support for Programming Languages and Operating Systems , ASPLOS...

    2019

  7. [15]

    https://github.com/clangd/clangd

    clangd language server, 2024. https://github.com/clangd/clangd

    2024

  8. [16]

    Clements, M

    Austin T. Clements, M. Frans Kaashoek, Nickolai Zeldovich, Robert T. Morris, and Eddie Kohler. The scalable commutativity rule: designing scalable software for multicore processors. InProceedings of the Twenty- Fourth ACM Symposium on Operating Systems Principles, SOSP ’13, pa...

    2013

  9. [17]

    A call to reconsider address-space isolation

    Jonathan Corbet. A call to reconsider address-space isolation. https: //lwn.net/Articles/909469/, 2022

    2022

  10. [18]

    Generalized address-space isolation

    Jonathan Corbet. Generalized address-space isolation. https://lwn.net/ Articles/886494/, 2022

    2022

  11. [19]

    Lockless algorithms for mere mortals, 2024

    Jonathan Corbet. Lockless algorithms for mere mortals, 2024. https: //lwn.net/Articles/827180/

    2024

  12. [20]

    Hcloud: Resource- efficient provisioning in shared cloud systems, 2016

    Christina Delimitrou and Christos Kozyrakis. Hcloud: Resource- efficient provisioning in shared cloud systems, 2016

    2016

  13. [21]

    Bolt: I know what you did last summer

    Christina Delimitrou and Christos Kozyrakis. Bolt: I know what you did last summer... in the cloud. In Proceedings of the Twenty-Second International Conference on Architectural Support for Programming Languages and Operating Systems , ASPLOS ’17, page 599–613, New York, NY, U...

    2017

  14. [22]

    The design and operation of cloudlab

    Dmitry Duplyakin, Robert Ricci, Aleksander Maricq, Gary Wong, Jonathon Duerig, Eric Eide, Leigh Stoller, Mike Hibler, David John- son, Kirk Webb, Aditya Akella, Kuangching Wang, Glenn Ricart, Larry Landweber, Chip Elliott, Michael Zink, Emmanuel Cecchet, Snigdhaswin Kar, and P...

    2019

  15. [23]

    Bpf performance tools: Linux system and application observability (chapter 2)

    Brendan Gregg. Bpf performance tools: Linux system and application observability (chapter 2). Addison-Wesley Professional, 2019

    2019

  16. [24]

    The return of the frame pointers

    Brendan Gregg. The return of the frame pointers. https: //www.brendangregg.com/blog/2024-03-17/the-return-of-the- frame-pointers.html, 2024

    2024

  17. [25]

    Ubik: efficient cache sharing with strict qos for latency-critical workloads

    Harshad Kasture and Daniel Sanchez. Ubik: efficient cache sharing with strict qos for latency-critical workloads. In Proceedings of the 19th International Conference on Architectural Support for Programming Languages and Operating Systems , ASPLOS ’14, page 729–742, New York, ...

    2014

  18. [26]

    Functionbench: A suite of work- loads for serverless cloud function service

    Jeongchul Kim and Kyungyong Lee. Functionbench: A suite of work- loads for serverless cloud function service. In 2019 IEEE 12th Inter- national Conference on Cloud Computing (CLOUD) , pages 502–504, 2019

    2019

  19. [27]

    Krohn and E

    M. Krohn and E. Tromer. Noninterference for a practical difc-based operating system. In 2009 30th IEEE Symposium on Security and Privacy, pages 61–76, 2009

    2009

  20. [28]

    Adve, Pradip Bose, and Jude A

    Xiaodong Li, Sarita V. Adve, Pradip Bose, and Jude A. Rivers. On- line estimation of architectural vulnerability factor for soft errors. In Proceedings of the 35th Annual International Symposium on Com- puter Architecture, ISCA ’08, page 341–352, USA, 2008. IEEE Computer Society

    2008

  21. [29]

    Design and verification of the arm confidential compute architecture

    Xupeng Li, Xuheng Li, Christoffer Dall, Ronghui Gu, Jason Nieh, Yousuf Sait, and Gareth Stockwell. Design and verification of the arm confidential compute architecture. In 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22) , pages 465–484, Carlsbad,...

    2022

  22. [30]

    Kit: Testing os-level virtualization for functional interference bugs

    Congyu Liu, Sishuai Gong, and Pedro Fonseca. Kit: Testing os-level virtualization for functional interference bugs. In Proceedings of the 28th ACM International Conference on Architectural Support for Pro- gramming Languages and Operating Systems, Volume 2 , ASPLOS 2023, page ...

    2023

  23. [31]

    Heracles: improving resource effi- ciency at scale

    David Lo, Liqun Cheng, Rama Govindaraju, Parthasarathy Ran- ganathan, and Christos Kozyrakis. Heracles: improving resource effi- ciency at scale. SIGARCH Comput. Archit. News, 43(3S):450–462, jun 2015

    2015

  24. [32]

    Lockdoc: Trace-based analysis of locking in the linux kernel

    Alexander Lochmann, Horst Schirmeier, Hendrik Borghorst, and Olaf Spinczyk. Lockdoc: Trace-based analysis of locking in the linux kernel. In Proceedings of the Fourteenth EuroSys Conference 2019 , EuroSys ’19, New York, NY, USA, 2019. Association for Computing Machinery

    2019

  25. [34]

    Understanding manycore scalability of file systems

    Changwoo Min, Sanidhya Kashyap, Steffen Maass, Woonhak Kang, and Taesoo Kim. Understanding manycore scalability of file systems. In Proceedings of the 2016 USENIX Conference on Usenix Annual Tech- nical Conference, USENIX ATC ’16, page 71–85, USA, 2016. USENIX Association

    2016

  26. [35]

    Mukherjee, Christopher Weaver, Joel Emer, Steven K

    Shubhendu S. Mukherjee, Christopher Weaver, Joel Emer, Steven K. Reinhardt, and Todd Austin. A systematic methodology to compute the architectural vulnerability factors for a high-performance micro- processor. In Proceedings of the 36th Annual IEEE/ACM International Symposium ...

    2003

  27. [36]

    Noninterference for operating system kernels

    Toby Murray, Daniel Matichuk, Matthew Brassil, Peter Gammie, and Gerwin Klein. Noninterference for operating system kernels. In Proceedings of the Second International Conference on Certified Programs and Proofs, CPP’12, page 126–142, Berlin, Heidelberg, 2012. Springer- Verlag

    2012

  28. [37]

    Arpaci-Dusseau, Remzi H

    Yuvraj Patel, Chenhao Ye, Akshat Sinha, Abigail Matthews, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau, and Michael M. Swift. 13 Conference’17, July 2017, Washington, DC, USA Anjali and Michael M. Swift Using Tr¯atr. to tame adversarial synchronization. In 31st USENIX Sec...

    2017

  29. [38]

    klockstat: An ebpf tool to monitor linux kernel lock contentions, August 2019

    Prathyush PV. klockstat: An ebpf tool to monitor linux kernel lock contentions, August 2019. https://prathyushpv.github.io/2019/04/30/ kLockStat.html

    2019

  30. [39]

    Qureshi and Yale N

    Moinuddin K. Qureshi and Yale N. Patt. Utility-based cache parti- tioning: A low-overhead, high-performance, runtime mechanism to partition shared caches. In 2006 39th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO’06) , pages 423–432, 2006

    2006

  31. [40]

    Vantage: scalable and effi- cient fine-grain cache partitioning

    Daniel Sanchez and Christos Kozyrakis. Vantage: scalable and effi- cient fine-grain cache partitioning. SIGARCH Comput. Archit. News, 39(3):57–68, jun 2011

    2011

  32. [41]

    Eraser: A dynamic data race detector for multithreaded programs

    Stefan Savage, Michael Burrows, Greg Nelson, Patrick Sobalvarro, and Thomas Anderson. Eraser: A dynamic data race detector for multithreaded programs. ACM Trans. Comput. Syst. , 15(4):391–411, nov 1997

    1997

  33. [42]

    Filebench: A flexible framework for file system benchmarking, 2016

    Vasily Tarasov, Erez Zadok, , and Spencer Shepler. Filebench: A flexible framework for file system benchmarking, 2016. https://www.usenix. org/system/files/login/articles/login_spring16_02_tarasov.pdf

    2016

  34. [43]

    Benchmarking, analysis, and optimization of serverless function snapshots

    Dmitrii Ustiugov, Plamen Petrov, Marios Kogias, Edouard Bugnion, and Boris Grot. Benchmarking, analysis, and optimization of serverless function snapshots. In Proceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating ...

  35. [44]

    Modeling and analysis of performance under interference in the cloud

    Scott Votke, Seyyed Ahmad Javadi, and Anshul Gandhi. Modeling and analysis of performance under interference in the cloud. In 2017 IEEE 25th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS) , pages 232–243, 2017

    2017

  36. [45]

    Non-blocking algorithm, 2024

    Wikipedia. Non-blocking algorithm, 2024. https://en.wikipedia.org/ wiki/Non-blocking_algorithm

    2024

  37. [46]

    Fletcher, and Josep Torrellas

    Zirui Neil Zhao, Adam Morrison, Christopher W. Fletcher, and Josep Torrellas. Untangle: A principled framework to design low-leakage, high-performance dynamic partitioning schemes. In Proceedings of the 28th ACM International Conference on Architectural Support for Pro- grammi...

    2023

  38. [2021]

    Association for Computing Machinery

Pith tools

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