속성:Evidence note
자료에서 확인할 수 있는 점이나 한계를 적습니다.
e
Verification: official DOI metadata and author publication page; abstract-level content; confidence=medium.
Canonical title: Exploring the Asynchrony of Slow Memory Filesystem with EasyIO
Question: How can storage I/O be overlapped with fine-grained GPU work without repeated CPU mediation and memory-movement overhead?
Context: GPU-accelerated storage paths pay for data movement, synchronization, and ordering around asynchronous requests.
Method: EasyIO offloads movement to on-chip DMA, exposes completion-buffer-centric orderless operations, uses two-level locking, and schedules DMA channels by traffic.
Evaluation: workloads=; baselines=; metrics=; results=The paper reports that fine-grained tasks can be interleaved transparently with asynchronous I/O; exact headline numbers were not recoverable from the accessible primary text.
Interpretation: Treat completion buffers, rather than submission order, as the unit that connects storage progress to GPU work.
Reusable lesson: Decouple request ordering from data readiness and schedule scarce copy engines explicitly.
Applicability: GPU storage runtimes with controllable DMA engines and many small independent tasks.
Limits: Primary-source access was limited to bibliographic and abstract-level material; workloads, baselines, and quantitative results remain unverified. +
Bibliographic paper record. +
Verification: official DOI metadata and author publication page; abstract-level content; confidence=medium.
Canonical title: EasyIO: Efficient Asynchronous I/O for GPU-Accelerated Storage Systems
Question: How can storage I/O be overlapped with fine-grained GPU work without repeated CPU mediation and memory-movement overhead?
Context: GPU-accelerated storage paths pay for data movement, synchronization, and ordering around asynchronous requests.
Method: EasyIO offloads movement to on-chip DMA, exposes completion-buffer-centric orderless operations, uses two-level locking, and schedules DMA channels by traffic.
Evaluation: workloads=; baselines=; metrics=; results=The paper reports that fine-grained tasks can be interleaved transparently with asynchronous I/O; exact headline numbers were not recoverable from the accessible primary text.
Interpretation: Treat completion buffers, rather than submission order, as the unit that connects storage progress to GPU work.
Reusable lesson: Decouple request ordering from data readiness and schedule scarce copy engines explicitly.
Applicability: GPU storage runtimes with controllable DMA engines and many small independent tasks.
Limits: Primary-source access was limited to bibliographic and abstract-level material; workloads, baselines, and quantitative results remain unverified. +
Verification: official USENIX page and abstract; confidence=medium.
Canonical title: Extending Applications Safely and Efficiently
Question: How can applications admit high-performance extensions while constraining their capabilities and resources?
Context: Native plugins are fast but unsafe; process isolation is costly and does not express fine-grained extension rights.
Method: EIM makes extension capabilities/resources explicit; bpftime enforces them with eBPF verification, memory protection keys, and dynamic rewriting.
Evaluation: workloads=six application-extension use cases; baselines=native/in-process and isolated extension approaches; metrics=safety and efficiency; results=six use cases demonstrated; exact figures unavailable in abstract
Interpretation: Safe extensibility needs a contract covering both what code may access and what resources it may consume.
Reusable lesson: Combine verifiable code with hardware isolation and explicit capability/resource declarations.
Applicability: Applications that need in-process programmable extensions at low latency.
Limits: Constrained by eBPF/verifier expressiveness and MPK availability; exact overhead was not extracted. +
Verification: official USENIX page and abstract; confidence=high.
Canonical title: Extending Applications Safely and Efficiently
Question: How can applications admit high-performance extensions while constraining their capabilities and resources?
Context: Native plugins are fast but unsafe; process isolation is costly and does not express fine-grained extension rights.
Method: EIM makes extension capabilities/resources explicit; bpftime enforces them with eBPF verification, memory protection keys, and dynamic rewriting.
Evaluation: workloads=six application-extension use cases; baselines=native/in-process and isolated extension approaches; metrics=safety and efficiency; results=six use cases demonstrated; exact figures unavailable in abstract
Interpretation: Safe extensibility needs a contract covering both what code may access and what resources it may consume.
Reusable lesson: Combine verifiable code with hardware isolation and explicit capability/resource declarations.
Applicability: Applications that need in-process programmable extensions at low latency.
Limits: Constrained by eBPF/verifier expressiveness and MPK availability; exact overhead was not extracted. +
Bibliographic paper record. +
extmem enabling application aware virtual memory management for data intensive applications 8a6dc0e4 +
Verification: official_abstract; confidence=high.
Question: Can applications express memory-management knowledge without replacing Linux VM or binding to one backend?
Context: General-purpose VM policies lack application semantics, while bespoke managers are hard to deploy and compare.
Method: ExtMem provides a Linux-compatible, backend-agnostic framework for application policies, multithreaded execution, telemetry, and incremental deployment.
Evaluation: workloads=data-intensive applications; names not stated in abstract; baselines=Linux VM and application-specific managers; metrics=performance; framework overhead; deployability; results=no numeric headline stated in official abstract
Interpretation: A common policy/mechanism interface can make application-aware VM practical and comparable.
Reusable lesson: Standardize the extension boundary before optimizing individual policies.
Applicability: Data-intensive Linux applications needing custom allocation, migration, or reclamation.
Limits: Applications must supply useful policy semantics; correctness and benefit remain policy- and backend-dependent. +
extmem enabling application aware virtual memory management for data intensive applications 8a6dc0e4 +
Bibliographic paper record. +
extmem enabling application aware virtual memory management for data intensive applications 8a6dc0e4 +
Verification: official_abstract; confidence=medium.
Question: Can applications express memory-management knowledge without replacing Linux VM or binding to one backend?
Context: General-purpose VM policies lack application semantics, while bespoke managers are hard to deploy and compare.
Method: ExtMem provides a Linux-compatible, backend-agnostic framework for application policies, multithreaded execution, telemetry, and incremental deployment.
Evaluation: workloads=data-intensive applications; names not stated in abstract; baselines=Linux VM and application-specific managers; metrics=performance; framework overhead; deployability; results=no numeric headline stated in official abstract
Interpretation: A common policy/mechanism interface can make application-aware VM practical and comparable.
Reusable lesson: Standardize the extension boundary before optimizing individual policies.
Applicability: Data-intensive Linux applications needing custom allocation, migration, or reclamation.
Limits: Applications must supply useful policy semantics; correctness and benefit remain policy- and backend-dependent. +
f
faasmem improving memory efficiency of serverless computing with memory pool architecture b6ab9eec +
Bibliographic paper record. +
faasmem improving memory efficiency of serverless computing with memory pool architecture b6ab9eec +
Verification: official_abstract; confidence=medium.
Canonical title: FaaSMem: Improving Memory Efficiency of Serverless Computing with Memory Pool Architecture
Question: Can serverless platforms reduce per-host reserved memory without hurting invocation latency?
Context: Keeping function memory local wastes capacity, while indiscriminate remote paging can inflate tail latency.
Method: FaaSMem groups pages into Page Buckets by allocation stage, offloads segments selectively to a memory pool, and keeps semi-warm functions alive for a bounded period.
Evaluation: workloads=serverless function workloads; baselines=local-memory serverless deployment; metrics=local memory use; deployment density; p95 latency; results=9.9–79.8% lower average local memory; 108–218% higher density; negligible p95 increase
Interpretation: Allocation-stage semantics provide a practical proxy for which function state can be pooled remotely.
Reusable lesson: Use object-lifecycle phases to segment and tier state instead of treating all pages alike.
Applicability: Serverless/FaaS clusters with a remote memory pool.
Limits: Relies on function lifetime/access regularity, remote-memory bandwidth, and evaluated serverless workloads. +
faasmem improving memory efficiency of serverless computing with memory pool architecture b6ab9eec +
Verification: official_abstract; confidence=medium.
Canonical title: FaaSMem: Improving Memory Efficiency of Serverless Computing with Memory Pool Architecture
Question: Can serverless platforms reduce per-host reserved memory without hurting invocation latency?
Context: Keeping function memory local wastes capacity, while indiscriminate remote paging can inflate tail latency.
Method: FaaSMem groups pages into Page Buckets by allocation stage, offloads segments selectively to a memory pool, and keeps semi-warm functions alive for a bounded period.
Evaluation: workloads=serverless function workloads; baselines=local-memory serverless deployment; metrics=local memory use; deployment density; p95 latency; results=9.9–79.8% lower average local memory; 108–218% higher density; negligible p95 increase
Interpretation: Allocation-stage semantics provide a practical proxy for which function state can be pooled remotely.
Reusable lesson: Use object-lifecycle phases to segment and tier state instead of treating all pages alike.
Applicability: Serverless/FaaS clusters with a remote memory pool.
Limits: Relies on function lifetime/access regularity, remote-memory bandwidth, and evaluated serverless workloads. +
Verification: official_abstract; confidence=medium.
Canonical title: Fast Core Scheduling with Userspace Process Abstraction
Question: Can applications reassign cores at sub-microsecond scale without giving userspace unrestricted kernel privilege?
Context: Kernel scheduling transitions are too slow for fine-grained colocation, while raw userspace scheduling weakens isolation.
Method: uProcess combines userspace interrupts and Memory Protection Keys to create a restricted privileged mode; Vessel uses it to reschedule cores and colocate latency-critical and best-effort work.
Evaluation: workloads=latency-critical and best-effort colocated workloads; baselines=kernel-based core scheduling; metrics=rescheduling latency; overall performance; tail latency; results=sub-microsecond rescheduling; no numeric speedup in accessible primary abstract
Interpretation: A hardware-protected userspace control plane can shorten scheduling paths without fully trusting applications.
Reusable lesson: Move frequent control decisions to a restricted userspace domain backed by hardware isolation.
Applicability: Low-latency core scheduling and colocated services on UINTR/MPK-capable CPUs.
Limits: Requires userspace interrupts, MPK, shared-process abstractions, and constrained syscall behavior; numeric evaluation not verified. +
Verification: official_abstract; confidence=medium.
Canonical title: Fast Core Scheduling with Userspace Process Abstraction
Question: Can applications reassign cores at sub-microsecond scale without giving userspace unrestricted kernel privilege?
Context: Kernel scheduling transitions are too slow for fine-grained colocation, while raw userspace scheduling weakens isolation.
Method: uProcess combines userspace interrupts and Memory Protection Keys to create a restricted privileged mode; Vessel uses it to reschedule cores and colocate latency-critical and best-effort work.
Evaluation: workloads=latency-critical and best-effort colocated workloads; baselines=kernel-based core scheduling; metrics=rescheduling latency; overall performance; tail latency; results=sub-microsecond rescheduling; no numeric speedup in accessible primary abstract
Interpretation: A hardware-protected userspace control plane can shorten scheduling paths without fully trusting applications.
Reusable lesson: Move frequent control decisions to a restricted userspace domain backed by hardware isolation.
Applicability: Low-latency core scheduling and colocated services on UINTR/MPK-capable CPUs.
Limits: Requires userspace interrupts, MPK, shared-process abstractions, and constrained syscall behavior; numeric evaluation not verified. +
Bibliographic paper record. +
Bibliographic paper record. +
Verification: official_abstract; confidence=medium.
Canonical title: Fast, Flexible, and Practical Kernel Extensions
Question: Can kernel extensions be more expressive than eBPF while preserving kernel safety and practical deployment?
Context: eBPF's verifier restricts programs; general native extensions make kernel resources vulnerable to extension faults.
Method: KFlex separates kernel-resource safety from extension-resource safety, using automated verification plus lightweight runtime checks while remaining backward-compatible with eBPF.
Evaluation: workloads=diverse kernel extensions and end-to-end applications; baselines=eBPF and existing extension mechanisms; metrics=performance; expressiveness; safety overhead; results=qualitative significant benefit; no numeric headline verified
Interpretation: Safety can be decomposed by ownership, allowing stronger guarantees for kernel state without proving every extension invariant statically.
Reusable lesson: Scope verification to shared critical resources and enforce private-state safety with cheaper runtime controls.
Applicability: Linux networking, observability, and in-kernel extension frameworks.
Limits: Runtime checks, cancellation, and verifier assumptions remain in the TCB; full upstream integration is incomplete. +
Verification: official_abstract; confidence=medium.
Canonical title: Fast, Flexible, and Practical Kernel Extensions
Question: Can kernel extensions be more expressive than eBPF while preserving kernel safety and practical deployment?
Context: eBPF's verifier restricts programs; general native extensions make kernel resources vulnerable to extension faults.
Method: KFlex separates kernel-resource safety from extension-resource safety, using automated verification plus lightweight runtime checks while remaining backward-compatible with eBPF.
Evaluation: workloads=diverse kernel extensions and end-to-end applications; baselines=eBPF and existing extension mechanisms; metrics=performance; expressiveness; safety overhead; results=qualitative significant benefit; no numeric headline verified
Interpretation: Safety can be decomposed by ownership, allowing stronger guarantees for kernel state without proving every extension invariant statically.
Reusable lesson: Scope verification to shared critical resources and enforce private-state safety with cheaper runtime controls.
Applicability: Linux networking, observability, and in-kernel extension frameworks.
Limits: Runtime checks, cancellation, and verifier assumptions remain in the TCB; full upstream integration is incomplete. +
Verification: arXiv abstract and DOI metadata; confidence=high.
Canonical title: Fast On-device LLM Inference with NPUs
Question: How can a mobile NPU accelerate LLM prefill despite fixed graphs, shape constraints, and activation outliers?
Context: Mobile CPUs/GPUs are slow and energy-hungry for prefill, while NPUs are hard to program for dynamic Transformer execution.
Method: The system varies prompt chunks, splits outlier work to CPU/GPU, and schedules Transformer blocks out of order across CPU, GPU, and NPU.
Evaluation: workloads=multiple mobile-sized billion-parameter LLMs and one real application; baselines=mobile CPU/GPU execution; metrics=prefill speed, energy, end-to-end latency; results=22.4x average prefill speedup; 30.7x average energy saving; up to 32.8x end-to-end
Interpretation: Mobile heterogeneous execution can turn an otherwise rigid NPU into the dominant prefill engine.
Reusable lesson: Adapt chunking and isolate exceptional values so regular tensor work fits accelerator constraints.
Applicability: On-device LLM inference on SoCs with CPU, GPU, and NPU.
Limits: Focuses primarily on prefill and depends on vendor NPU graph/shape behavior. +
Bibliographic paper record. +