속성:Evidence note
자료에서 확인할 수 있는 점이나 한계를 적습니다.
f
Verification: arXiv abstract and DOI metadata; confidence=medium.
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. +
Verification: official_abstract; confidence=high.
Canonical title: Fast (Trapless) Kernel Probes Everywhere
Question: Can Linux Kprobes avoid trap overhead without sacrificing broad kernel-code coverage?
Context: Standard Kprobes trap on every hit; optimized probes are faster but cannot instrument much kernel code.
Method: The compiler/linker places strategic NOPs that a transparent Kprobe implementation can patch into trapless probes across nearly all code.
Evaluation: workloads=Linux kernel probe sites; baselines=standard Kprobe; prior optimized Kprobe; metrics=probe cost; kernel-code coverage; results=10x probe performance; 96% coverage vs about 80%
Interpretation: Small compile-time layout support removes a runtime observability tax while preserving compatibility.
Reusable lesson: Reserve cheap patch points during build time for production-safe dynamic instrumentation.
Applicability: Linux tracing, observability, and security instrumentation.
Limits: Needs toolchain/kernel-layout changes; some code and architectures remain unsupported. +
Verification: official_abstract; confidence=medium.
Canonical title: Fast (Trapless) Kernel Probes Everywhere
Question: Can Linux Kprobes avoid trap overhead without sacrificing broad kernel-code coverage?
Context: Standard Kprobes trap on every hit; optimized probes are faster but cannot instrument much kernel code.
Method: The compiler/linker places strategic NOPs that a transparent Kprobe implementation can patch into trapless probes across nearly all code.
Evaluation: workloads=Linux kernel probe sites; baselines=standard Kprobe; prior optimized Kprobe; metrics=probe cost; kernel-code coverage; results=10x probe performance; 96% coverage vs about 80%
Interpretation: Small compile-time layout support removes a runtime observability tax while preserving compatibility.
Reusable lesson: Reserve cheap patch points during build time for production-safe dynamic instrumentation.
Applicability: Linux tracing, observability, and security instrumentation.
Limits: Needs toolchain/kernel-layout changes; some code and architectures remain unsupported. +
Bibliographic paper record. +
Verification: official_abstract; confidence=medium.
Question: Can Linux memory-prefetch policies be customized safely without maintaining kernel forks?
Context: Kernel-resident prefetch policies are hard to prototype, deploy, and tailor per workload.
Method: FetchBPF exposes memory-prefetch hooks and policy state through eBPF, enabling verified user-defined policies in a stock-kernel framework.
Evaluation: workloads=prefetch policies reproduced from prior work; baselines=equivalent native-kernel policies; metrics=runtime overhead; prefetch effectiveness; results=negligible framework overhead
Interpretation: A constrained programmable interface can preserve performance while shortening policy iteration and deployment.
Reusable lesson: Move policy into a safe extension layer while keeping mechanisms in the kernel.
Applicability: Linux VM prefetch experimentation and workload-specific deployment.
Limits: The demonstrated domain is prefetching; eBPF verifier and helper interfaces bound policy expressiveness. +
Bibliographic paper record. +
Verification: official_abstract; confidence=high.
Question: Can Linux memory-prefetch policies be customized safely without maintaining kernel forks?
Context: Kernel-resident prefetch policies are hard to prototype, deploy, and tailor per workload.
Method: FetchBPF exposes memory-prefetch hooks and policy state through eBPF, enabling verified user-defined policies in a stock-kernel framework.
Evaluation: workloads=prefetch policies reproduced from prior work; baselines=equivalent native-kernel policies; metrics=runtime overhead; prefetch effectiveness; results=negligible framework overhead
Interpretation: A constrained programmable interface can preserve performance while shortening policy iteration and deployment.
Reusable lesson: Move policy into a safe extension layer while keeping mechanisms in the kernel.
Applicability: Linux VM prefetch experimentation and workload-specific deployment.
Limits: The demonstrated domain is prefetching; eBPF verifier and helper interfaces bound policy expressiveness. +
Verification: abstract_only; confidence=medium.
Canonical title: FIFO queues are all you need for cache eviction
Question: 복잡한 캐시 축출 알고리즘 없이도 높은 hit ratio와 확장성을 얻을 수 있는가?
Context: LRU 계열은 동시성·메타데이터 비용이 크고 스캔 오염에 약하다.
Method: S3-FIFO는 세 FIFO 큐와 빠른 강등으로 최근성·빈도·일회성 객체를 분리한다.
Evaluation: workloads=6,594 traces; 14 datasets; baselines=optimized LRU; state-of-the-art eviction algorithms; metrics=miss ratio; throughput; results=Best mean miss ratio on 10/14 datasets; 6× throughput vs 16-thread LRU.
Interpretation: 간단한 입장·퇴장 규칙만으로도 복잡한 전역 순서 유지 비용을 피할 수 있다.
Reusable lesson: 캐시 정책은 miss ratio와 동시성 비용을 함께 최적화하라.
Applicability: 웹·블록·객체 캐시.
Limits: 결과는 트레이스와 캐시 크기에 의존하고 모든 워크로드에서 우세하지는 않다.
Canonical title: FIFO queues are all you need for cache eviction +
Bibliographic paper record. +
Verification: abstract_only; confidence=high.
Canonical title: FIFO Queues Are All You Need for Cache Eviction
Question: 복잡한 캐시 축출 알고리즘 없이도 높은 hit ratio와 확장성을 얻을 수 있는가?
Context: LRU 계열은 동시성·메타데이터 비용이 크고 스캔 오염에 약하다.
Method: S3-FIFO는 세 FIFO 큐와 빠른 강등으로 최근성·빈도·일회성 객체를 분리한다.
Evaluation: workloads=6,594 traces; 14 datasets; baselines=optimized LRU; state-of-the-art eviction algorithms; metrics=miss ratio; throughput; results=Best mean miss ratio on 10/14 datasets; 6× throughput vs 16-thread LRU.
Interpretation: 간단한 입장·퇴장 규칙만으로도 복잡한 전역 순서 유지 비용을 피할 수 있다.
Reusable lesson: 캐시 정책은 miss ratio와 동시성 비용을 함께 최적화하라.
Applicability: 웹·블록·객체 캐시.
Limits: 결과는 트레이스와 캐시 크기에 의존하고 모든 워크로드에서 우세하지는 않다. +
정본 Lesson 보강 근거. 검토 원본: Lesson:technical_review_filter_lsm_tree_4641bf5f. 확인 범위: partial_source. 세부 범위: official_abstract_partial. 확인한 자료: https://www.dbpia.co.kr/journal/articleDetail?nodeId=NODE11224364 ; https://cslab.yonsei.ac.kr/publications. 질문, 방법, 평가, 해석, 재사용 교훈, 적용 범위와 한계를 같은 Lesson 본문에 통합했습니다. +
Full Korean bibliographic citation is preserved in the lesson evidence field; this ASCII citation is used for adapter compatibility. +
Verification: official_abstract; confidence=medium.
Canonical title: FleetIO: Managing Multi-Tenant Cloud Storage with Multi-Agent Reinforcement Learning
Question: Can virtualized SSDs dynamically harvest unused capacity/bandwidth while preserving each tenant's tail-latency SLO?
Context: Software isolation improves utilization but has weak tails; hardware isolation protects tenants but strands storage resources.
Method: FleetIO uses multi-agent RL integrated with storage scheduling, clusters runtime traces into latency- or bandwidth-oriented types, and tunes rewards for fine-grained harvesting.
Evaluation: workloads=diverse cloud applications; runtime I/O traces; real programmable SSD board; baselines=state-of-the-art storage sharing approaches; metrics=storage utilization; I/O tail latency; SLO impact; results=up to 1.4x utilization; 1.5x lower average tail latency
Interpretation: Adaptive workload classification and type-specific rewards let learning balance isolation against utilization as conditions change.
Reusable lesson: For multi-objective resource sharing, condition policies and rewards on workload class and expose actions directly to the scheduler.
Applicability: Multi-tenant cloud SSD virtualization and programmable storage.
Limits: RL behavior depends on training coverage, reward tuning, trace stationarity, programmable-device features, and SLO definitions. +
Verification: official_abstract; confidence=high.
Canonical title: FleetIO: Managing Multi-Tenant Cloud Storage with Multi-Agent Reinforcement Learning
Question: Can virtualized SSDs dynamically harvest unused capacity/bandwidth while preserving each tenant's tail-latency SLO?
Context: Software isolation improves utilization but has weak tails; hardware isolation protects tenants but strands storage resources.
Method: FleetIO uses multi-agent RL integrated with storage scheduling, clusters runtime traces into latency- or bandwidth-oriented types, and tunes rewards for fine-grained harvesting.
Evaluation: workloads=diverse cloud applications; runtime I/O traces; real programmable SSD board; baselines=state-of-the-art storage sharing approaches; metrics=storage utilization; I/O tail latency; SLO impact; results=up to 1.4x utilization; 1.5x lower average tail latency
Interpretation: Adaptive workload classification and type-specific rewards let learning balance isolation against utilization as conditions change.
Reusable lesson: For multi-objective resource sharing, condition policies and rewards on workload class and expose actions directly to the scheduler.
Applicability: Multi-tenant cloud SSD virtualization and programmable storage.
Limits: RL behavior depends on training coverage, reward tuning, trace stationarity, programmable-device features, and SLO definitions. +
Bibliographic paper record. +
Bibliographic paper record. +
Verification: full_text; confidence=high.
Canonical title: FlexMem: Adaptive Page Profiling and Migration for Tiered Memory
Question: How can tiered memory adapt profiling and migration to workloads whose hot sets and phase behavior differ?
Context: Fixed sampling and promotion/demotion thresholds either miss hot pages or spend too much on profiling and movement.
Method: FlexMem combines performance counters with hint faults, dynamically adjusts demotion volume, and tracks warm-page ranges.
Evaluation: workloads=common memory-intensive benchmarks; baselines=Tiering-0.8; TPP; MEMTIS; metrics=application performance; profiling overhead; migration efficiency; results=32% average over Tiering-0.8; 23% over TPP; 27% over MEMTIS
Interpretation: Profiling fidelity and migration aggressiveness should be controlled together from workload feedback.
Reusable lesson: Adapt both measurement cost and actuation strength, not just the placement threshold.
Applicability: Linux heterogeneous/tiered-memory systems.
Limits: Tuning and gains depend on hardware counters, memory topology, migration costs, and workload phase length. +
Verification: full_text; confidence=high.
Canonical title: FlexMem: Adaptive Page Profiling and Migration for Tiered Memory
Question: How can tiered memory adapt profiling and migration to workloads whose hot sets and phase behavior differ?
Context: Fixed sampling and promotion/demotion thresholds either miss hot pages or spend too much on profiling and movement.
Method: FlexMem combines performance counters with hint faults, dynamically adjusts demotion volume, and tracks warm-page ranges.
Evaluation: workloads=common memory-intensive benchmarks; baselines=Tiering-0.8; TPP; MEMTIS; metrics=application performance; profiling overhead; migration efficiency; results=32% average over Tiering-0.8; 23% over TPP; 27% over MEMTIS
Interpretation: Profiling fidelity and migration aggressiveness should be controlled together from workload feedback.
Reusable lesson: Adapt both measurement cost and actuation strength, not just the placement threshold.
Applicability: Linux heterogeneous/tiered-memory systems.
Limits: Tuning and gains depend on hardware counters, memory topology, migration costs, and workload phase length. +
following the data not the function rethinking function orchestration in serverless computing 5edeca75 +
Verification: abstract_only; confidence=high.
Canonical title: Following the Data, Not the Function: Rethinking Function Orchestration in Serverless Computing
Question: 서버리스 워크플로를 함수 호출 순서가 아니라 데이터 흐름으로 오케스트레이션할 수 있는가?
Context: 기존 플랫폼은 중간 데이터 교환을 몰라 개발자가 복잡한 상호작용을 직접 구현한다.
Method: Pheromone은 data bucket과 다양한 data trigger로 데이터 소비가 다음 함수를 구동하게 한다.
Evaluation: workloads=complex serverless workflows; baselines=commercial serverless platforms; open-source platforms; metrics=function interaction latency; data-exchange latency; scalability; results=Orders-of-magnitude latency reduction; exact figure not abstract-verified.
Interpretation: 데이터 의존성을 1급 추상화하면 오케스트레이션과 데이터 전송을 함께 최적화할 수 있다.
Reusable lesson: 워크플로 DAG의 제어면을 실제 데이터 흐름과 분리하지 말라.
Applicability: 데이터 집약 serverless workflow.
Limits: 새 bucket/trigger 프로그래밍 모델 도입이 필요하고 정확한 수치는 초록에 없다. +
following the data not the function rethinking function orchestration in serverless computing 5edeca75 +
Verification: abstract_only; confidence=medium.
Canonical title: Following the Data, Not the Function: Rethinking Function Orchestration in Serverless Computing
Question: 서버리스 워크플로를 함수 호출 순서가 아니라 데이터 흐름으로 오케스트레이션할 수 있는가?
Context: 기존 플랫폼은 중간 데이터 교환을 몰라 개발자가 복잡한 상호작용을 직접 구현한다.
Method: Pheromone은 data bucket과 다양한 data trigger로 데이터 소비가 다음 함수를 구동하게 한다.
Evaluation: workloads=complex serverless workflows; baselines=commercial serverless platforms; open-source platforms; metrics=function interaction latency; data-exchange latency; scalability; results=Orders-of-magnitude latency reduction; exact figure not abstract-verified.
Interpretation: 데이터 의존성을 1급 추상화하면 오케스트레이션과 데이터 전송을 함께 최적화할 수 있다.
Reusable lesson: 워크플로 DAG의 제어면을 실제 데이터 흐름과 분리하지 말라.
Applicability: 데이터 집약 serverless workflow.
Limits: 새 bucket/trigger 프로그래밍 모델 도입이 필요하고 정확한 수치는 초록에 없다. +