{"id":"c2a9ab20-dc08-497c-9a7e-e8f3ff8ba682","arxiv_id":"2507.21248","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Measuring shared kernel lock acquisitions across co-located workloads provides a quantitative proxy for platform isolation and pinpoints the file-system journal and page allocator as top interference sources.","lead":"Researchers built a tool that watches which kernel locks two running cloud workloads share, using that as a ruler for how much they interfere. The tool finds file-system journaling and page allocation are the top interference points, and that stronger isolation platforms like Firecracker share fewer locks.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Shared-lock acquisition rates are never tied to actual contention or to the trasher's lock usage, so the central claim that lock frequency measures isolation remains unsupported.","rationale":"The reader's weakest assumption is that shared lock acquisitions, rather than actual contention, are a valid proxy for interference, and that the Section 7 trasher is not shown to acquire the same locks as the workload. My reading agrees with this and adds a concrete internal inconsistency: Table 5 gives runc's mem-8KB shared lock rate as 0.0016, yet Section 7.1.1 reports runc degrading under memory load, while fc has a high rate and does not degrade. This makes the central claim conditional on a missing validation step that the paper does not provide. The LockScope tool and the qualitative lock-usage data are useful contributions, and the static analysis plus dynamic tracing are plausible engineering, but the central assertion that shared-lock frequency measures isolation is not established by the evidence as presented. The reader's CONDITIONAL verdict is therefore appropriate; I do not see a reason to move to ACCEPT or REJECT based on the text alone. The proposed concrete test would settle the concern by directly connecting trasher lock behavior, contention, and observed performance.","tokens_in":17381,"tokens_out":3667,"duration_ms":47128,"concrete_test":"Re-run the Section 7.1.1 memory-stress experiment with LockScope tracing enabled on both the worker and the trasher processes. Record (a) which locks each side acquires, (b) whether acquisitions of zone->lock and lruvec->lru_lock overlap in time or involve waiting, and (c) worker execution time. The metric is validated only if the trashers show a non-negligible common-lock acquisition rate and the rank order of common-lock rates across host, runc, runsc, and fc matches the degradation ordering in Figure 4. As a control, run a trasher that hammers a disjoint lock, such as a filesystem journal lock, and show that degradation tracks lock overlap rather than raw system-call rate; if runc still degrades with near-zero common-lock rate, the central claim fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The abstract and Section 3 assert that synchronization frequency between workloads measures their ability to interfere, but the operational metric in Section 5.2 is the count and rate of lock acquisitions, not contention. Two workloads can acquire the same lock at disjoint times and never wait on each other, while genuine interference requires temporal overlap; conversely, RCU and atomic paths are excluded even when they serialize. Section 7 is the only attempt to validate the metric, yet the trasher described in Section 5.3 is never traced, so nothing in the paper shows that it acquires the same locks as the worker. The degradation in Figures 4-6 could therefore come from CPU, memory bandwidth, cache, or disk pressure rather than from the shared kernel objects identified in Section 6. The paper even contains internal tension: Table 5 reports runc's mem-8KB shared lock rate as 0.0016 and shared lock count as 0.33, yet Section 7.1.1 reports runc degrades under memory load; by the paper's own metric, runc should be nearly immune to lock-based interference in that experiment. Similarly, fc has a high shared lock rate (399) but shows no degradation after startup, so acquisition rate alone does not order interference. Without a demonstrated link between common-acquisition rate and actual contention or slowdown, the central claim remains an assertion.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":17544,"tokens_out":6254,"duration_ms":68388,"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":[{"comment":"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.","section":"Section 3, Section 5.2, Table 5"},{"comment":"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.","section":"Section 5.3, Section 7, Figures 4-6"},{"comment":"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.'","section":"Section 7.1.1 vs Table 5"},{"comment":"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.","section":"Sections 2 and 3"}],"minor_comments":[{"comment":"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.","section":"Section 5.2, Table 5"},{"comment":"The sentence 'However, it does has have a higher execution time...' should read 'it does have a higher execution time...'.","section":"Section 7.1.1"},{"comment":"References [33] and [34] are the same paper (Min et al., 'Understanding manycore scalability of file systems') and should be merged to avoid duplication.","section":"References"},{"comment":"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.","section":"Section 4.2"},{"comment":"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.","section":"Section 6.2.1"}],"recommendation":"major_revision","confidential_remarks":"The paper's idea fits a systems/OS venue and the measurement dataset is substantial, but the central metric needs contention-level validation before publication. Please also consider requesting the tool and scripts as an artifact; the paper would be stronger with a release of LockScope and the experimental harness."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's my take on Anjali and Swift's kernel-lock isolation paper. It's a useful first-step measurement study, but the headline claim—that the rate of shared lock acquisitions measures isolation—is not established by the data in the paper.\n\nWhat's genuinely new: the cross-platform comparison of shared kernel locks across host, runc, gVisor, and Firecracker, and the LockScope tool that combines eBPF tracing with a clangd-based static analyzer to map locks to kernel objects. The empirical finding that the ext4 journal and the page allocator zone->lock dominate cross-workload sharing is concrete and worth knowing. The qualitative pattern across platforms—runc and host share more, Firecracker much less—is consistent with expectations and gives the paper credibility.\n\nThe soft spots are real and load-bearing. The central premise, stated in Section 3, is that the frequency of synchronization between workloads measures their ability to interfere. But the paper never ties lock acquisition frequency to actual contention. Two workloads can acquire the same lock at disjoint times and never wait; the metric counts those as shared. That alone would be a minor caveat, but the validation doesn't close the gap. Section 7's trasher is never traced, so we don't know whether it shares locks with the worker; CPU, cache, and DRAM pressure are plausible alternative explanations for the observed slowdowns. Figures 4–6 have no error bars (three runs, averaged). And there's an internal tension: runc's shared lock rate for mem-8KB is 0.0016, yet runc still degrades under memory load, while Firecracker has a high shared lock rate (399) and shows no post-startup degradation. That suggests the metric, as defined, does not order interference.\n\nWhat the paper does well is scope the problem and build a tool that can be refined. The static analysis is a real engineering contribution. But the central claim in the abstract and Section 3 goes beyond what the evidence supports. The paper itself is honest in places—it calls the approach a first step—but the framing overstates.\n\nWho should read this: people working on cloud isolation or kernel scalability, particularly on co-placement decisions. It deserves peer review because the problem is important and the tooling is original, but the referee should ask for validation that ties lock sharing to actual contention (e.g., measure lock wait times, trace the trasher, and show the metric predicts slowdowns across workloads). Without that, it's a strong workshop paper rather than a settled result.","headline":"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.","tokens_in":18124,"tokens_out":2776,"would_cite":true,"duration_ms":31557,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["kernel locks","isolation measurement","performance interference","eBPF tracing","shared kernel data structures","containers","microVMs","Linux kernel"],"falsifier":"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.","tokens_in":17106,"feed_emoji":"🔒","tokens_out":6915,"duration_ms":74230,"temperature":0.7,"pith_summary":"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.","feed_headline":"Kernel lock traces measure cloud workload isolation","feed_subtitle":"File-system journal and page allocator top the list of shared-lock interference sources across four platforms.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the eBPF lock-acquisition tracing that LockScope's dynamic tracer extends into a full workload lock trace.","marker":"[38]"},{"why":"Provides the symbol and AST queries that the static analyzer uses to resolve stacks and map locks to objects.","marker":"[15]"},{"why":"Provides the file-metadata benchmarks whose results expose the journal and inode-hash locks as top shared structures.","marker":"[42]"},{"why":"Supplies the six serverless application workloads whose lock traces are measured across all platforms.","marker":"[26]"},{"why":"Supplies the Feedsim and video-transcoding cloud workloads used in the cloud workload comparison.","marker":"[6]"},{"why":"Supplies the graph analytics and data caching cloud workloads used where other cloud benchmarks could not run on gVisor.","marker":"[5]"},{"why":"Provides the prior file-system scalability analysis that motivates treating kernel objects such as the journal as contention points.","marker":"[33]"},{"why":"Explains gVisor's two-level memory mapping, which the paper uses to explain that platform's lower baseline and post-startup lock behavior.","marker":"[3]"}],"fun_headline_variants":["Locked in, leaked out: kernel locks quantify isolation","Kernel locks reveal hidden cloud interference","Shared locks expose poor workload isolation","Journal and allocator locks dominate interference","Measuring multi-tenant isolation via kernel locks"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Locked in, leaked out: kernel locks quantify isolation","Kernel locks reveal hidden cloud interference","Shared locks expose poor workload isolation","Journal and allocator locks dominate interference","Measuring multi-tenant isolation via kernel locks"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000374,"raw_usage":{"total_tokens":1987,"prompt_tokens":929,"completion_tokens":1058,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":545,"completion_tokens_details":{"reasoning_tokens":993}},"tokens_in":545,"tokens_out":1058,"duration_ms":11054,"temperature":1.0,"reasoning_tokens":993,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T12:57:16.999465+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"klockstat: An ebpf tool to monitor linux kernel lock contentions, August 2019","cited_arxiv_id":null,"evidence_quote":"Supplies the eBPF lock-acquisition tracing that LockScope's dynamic tracer extends into a full workload lock trace."},{"cited_title":"https://github.com/clangd/clangd","cited_arxiv_id":null,"evidence_quote":"Provides the symbol and AST queries that the static analyzer uses to resolve stacks and map locks to objects."},{"cited_title":"Filebench: A flexible framework for file system benchmarking, 2016","cited_arxiv_id":null,"evidence_quote":"Provides the file-metadata benchmarks whose results expose the journal and inode-hash locks as top shared structures."},{"cited_title":"Functionbench: A suite of work- loads for serverless cloud function service","cited_arxiv_id":null,"evidence_quote":"Supplies the six serverless application workloads whose lock traces are measured across all platforms."},{"cited_title":"https://github.com/facebookresearch/DCPerf","cited_arxiv_id":null,"evidence_quote":"Supplies the Feedsim and video-transcoding cloud workloads used in the cloud workload comparison."},{"cited_title":"https://www","cited_arxiv_id":null,"evidence_quote":"Supplies the graph analytics and data caching cloud workloads used where other cloud benchmarks could not run on gVisor."},{"cited_title":"https://github.com/google/gvisor/tree/master/pkg/ sentry/mm","cited_arxiv_id":null,"evidence_quote":"Explains gVisor's two-level memory mapping, which the paper uses to explain that platform's lower baseline and post-startup lock behavior."}],"review_version":1}