속성:Evidence note
자료에서 확인할 수 있는 점이나 한계를 적습니다.
a
achieving low latency graph based vector search via aligning best first search algorithm with ss 77c9550f +
Verification: official USENIX page and abstract; confidence=high.
Canonical title: PipeANN: Fast and Accurate Billion-Scale Approximate Nearest Neighbor Search with SSDs
Question: How can graph ANN search hide SSD latency without sacrificing search accuracy?
Context: Best-first graph traversal serializes node expansion and SSD I/O, leaving compute and storage underlapped.
Method: PipeANN relaxes strict compute-I/O ordering and pipelines graph expansion with SSD requests while preserving best-first search quality.
Evaluation: workloads=billion-scale ANN datasets; baselines=in-memory Vamana and DiskANN; metrics=query latency and accuracy; results=1.14–2.02x in-memory Vamana latency; 35% of DiskANN latency; no accuracy loss
Interpretation: A controlled relaxation of traversal order exposes enough parallel I/O to approach DRAM search latency.
Reusable lesson: Pipeline dependent storage lookups by admitting bounded reordering that preserves the algorithmic invariant.
Applicability: SSD-resident graph ANN indexes at billion-vector scale.
Limits: Reported relation to in-memory Vamana is still slower; gains depend on graph/search and SSD characteristics. +
achieving low latency graph based vector search via aligning best first search algorithm with ss 77c9550f +
Verification: official USENIX page and abstract; confidence=medium.
Canonical title: Achieving Low-Latency Graph-Based Vector Search via Aligning Best-First Search Algorithm with SSD
Question: How can graph ANN search hide SSD latency without sacrificing search accuracy?
Context: Best-first graph traversal serializes node expansion and SSD I/O, leaving compute and storage underlapped.
Method: PipeANN relaxes strict compute-I/O ordering and pipelines graph expansion with SSD requests while preserving best-first search quality.
Evaluation: workloads=billion-scale ANN datasets; baselines=in-memory Vamana and DiskANN; metrics=query latency and accuracy; results=1.14–2.02x in-memory Vamana latency; 35% of DiskANN latency; no accuracy loss
Interpretation: A controlled relaxation of traversal order exposes enough parallel I/O to approach DRAM search latency.
Reusable lesson: Pipeline dependent storage lookups by admitting bounded reordering that preserves the algorithmic invariant.
Applicability: SSD-resident graph ANN indexes at billion-vector scale.
Limits: Reported relation to in-memory Vamana is still slower; gains depend on graph/search and SSD characteristics. +
achieving low latency graph based vector search via aligning best first search algorithm with ss 77c9550f +
Bibliographic paper record. +
Verification: abstract_only; confidence=medium.
Canonical title: Achieving Microsecond-Scale Tail Latency Efficiently with Approximate Optimal Scheduling
Question: 엄격한 선점이나 단일 큐 없이 μs 꼬리 지연 SLO를 효율적으로 지킬 수 있는가?
Context: 최적 스케줄링은 계산비가 크고 기존 근사는 처리량·공정성을 희생한다.
Method: Concord는 응용 비종속 근사 최적 스케줄링으로 다중 큐·비엄격 선점을 사용한다.
Evaluation: workloads=microbenchmarks; LevelDB; baselines=state-of-the-art low-latency schedulers; metrics=throughput at equal tail-latency SLO; results=Up to 52% and 83% higher throughput.
Interpretation: 완전 최적 대신 빠른 근사와 유연한 큐 구조가 μs SLO에 실용적이다.
Reusable lesson: 초저지연 스케줄러는 최적성 오차와 실행 오버헤드를 함께 최소화하라.
Applicability: μs RPC·KV 서비스.
Limits: 특정 서비스 시간 분포·SLO와 근사 모델 가정에 민감하다. +
Bibliographic paper record. +
Verification: abstract_only; confidence=high.
Canonical title: Achieving Microsecond-Scale Tail Latency Efficiently with Approximate Optimal Scheduling
Question: 엄격한 선점이나 단일 큐 없이 μs 꼬리 지연 SLO를 효율적으로 지킬 수 있는가?
Context: 최적 스케줄링은 계산비가 크고 기존 근사는 처리량·공정성을 희생한다.
Method: Concord는 응용 비종속 근사 최적 스케줄링으로 다중 큐·비엄격 선점을 사용한다.
Evaluation: workloads=microbenchmarks; LevelDB; baselines=state-of-the-art low-latency schedulers; metrics=throughput at equal tail-latency SLO; results=Up to 52% and 83% higher throughput.
Interpretation: 완전 최적 대신 빠른 근사와 유연한 큐 구조가 μs SLO에 실용적이다.
Reusable lesson: 초저지연 스케줄러는 최적성 오차와 실행 오버헤드를 함께 최소화하라.
Applicability: μs RPC·KV 서비스.
Limits: 특정 서비스 시간 분포·SLO와 근사 모델 가정에 민감하다. +
Verification: official_abstract; confidence=medium.
Question: Can an LSM store adapt compaction as its read/write pattern changes over time?
Context: Fixed compaction policies optimize one workload phase and can cause stalls or read amplification in another.
Method: DOPA-DB divides the key space into ranges and dynamically changes compaction size: restrained in write-heavy phases and aggressive in read-heavy phases.
Evaluation: workloads=preliminary LSM experiments; baselines=; metrics=read/write performance; compaction overhead; stalls; results=qualitative potential benefit only
Interpretation: Compaction intensity should follow both time-varying workload mix and key-range behavior.
Reusable lesson: Make background-maintenance budgets phase- and range-aware.
Applicability: LSM key-value stores with shifting read/write ratios.
Limits: Preliminary workshop study; accessible primary abstract does not provide complete workloads, baselines, or numbers. +
Bibliographic paper record. +
Verification: official_abstract; confidence=medium.
Question: Can an LSM store adapt compaction as its read/write pattern changes over time?
Context: Fixed compaction policies optimize one workload phase and can cause stalls or read amplification in another.
Method: DOPA-DB divides the key space into ranges and dynamically changes compaction size: restrained in write-heavy phases and aggressive in read-heavy phases.
Evaluation: workloads=preliminary LSM experiments; baselines=; metrics=read/write performance; compaction overhead; stalls; results=qualitative potential benefit only
Interpretation: Compaction intensity should follow both time-varying workload mix and key-range behavior.
Reusable lesson: Make background-maintenance budgets phase- and range-aware.
Applicability: LSM key-value stores with shifting read/write ratios.
Limits: Preliminary workshop study; accessible primary abstract does not provide complete workloads, baselines, or numbers. +
aegonkv a high bandwidth low tail latency and low storage cost kv separated lsm store with smart 5a081f42 +
Bibliographic paper record. +
aegonkv a high bandwidth low tail latency and low storage cost kv separated lsm store with smart 5a081f42 +
Verification: official_abstract; confidence=medium.
Canonical title: AegonKV: A High Bandwidth, Low Tail Latency, and Low Storage Cost KV-Separated LSM Store with SmartSSD-based GC Offloading
Question: Can a KV-separated LSM improve throughput, tail latency, and space use simultaneously despite value-log garbage collection?
Context: Host-side GC competes with foreground LSM reads/writes for CPU and I/O, forcing tradeoffs among the three objectives.
Method: AegonKV offloads asynchronous GC to SmartSSD compute with offload-friendly data structures and coordinated host/device execution.
Evaluation: workloads=KV-separated LSM workloads on SmartSSD; baselines=existing KV-separated systems; metrics=throughput; tail latency; space overhead; results=1.28–3.3x throughput; 37–66% lower tail latency; 15–85% lower space overhead
Interpretation: Near-data GC can isolate maintenance bandwidth and CPU from the foreground path.
Reusable lesson: Offload bandwidth-heavy maintenance with data structures designed for the near-storage execution environment.
Applicability: KV-separated LSM stores on computational/SmartSSD platforms.
Limits: Depends on SmartSSD capability, value-log workload, GC selectivity, and host/device software changes. +
aegonkv a high bandwidth low tail latency and low storage cost kv separated lsm store with smart 5a081f42 +
Verification: official_abstract; confidence=high.
Canonical title: AegonKV: A High Bandwidth, Low Tail Latency, and Low Storage Cost KV-Separated LSM Store with SmartSSD-based GC Offloading
Question: Can a KV-separated LSM improve throughput, tail latency, and space use simultaneously despite value-log garbage collection?
Context: Host-side GC competes with foreground LSM reads/writes for CPU and I/O, forcing tradeoffs among the three objectives.
Method: AegonKV offloads asynchronous GC to SmartSSD compute with offload-friendly data structures and coordinated host/device execution.
Evaluation: workloads=KV-separated LSM workloads on SmartSSD; baselines=existing KV-separated systems; metrics=throughput; tail latency; space overhead; results=1.28–3.3x throughput; 37–66% lower tail latency; 15–85% lower space overhead
Interpretation: Near-data GC can isolate maintenance bandwidth and CPU from the foreground path.
Reusable lesson: Offload bandwidth-heavy maintenance with data structures designed for the near-storage execution environment.
Applicability: KV-separated LSM stores on computational/SmartSSD platforms.
Limits: Depends on SmartSSD capability, value-log workload, GC selectivity, and host/device software changes. +
Verification: arXiv abstract, official DOI metadata, and author publication page; confidence=medium.
Canonical title: AGILE: Lightweight and Efficient Asynchronous GPU-SSD Integration
Question: Can GPU threads issue SSD I/O asynchronously without deadlock while using HBM as a flexible software cache?
Context: Prior GPU-centric NVMe paths are synchronous, stalling threads during device latency.
Method: AGILE provides GPU-native asynchronous requests with deadlock-safe progress and a configurable HBM software cache.
Evaluation: workloads=CTC micro/workloads, DLRM, graph applications; baselines=synchronous GPU I/O and BaM; metrics=performance, API overhead, register use; results=1.88x; 1.75x vs BaM; 3.12x/2.85x lower overhead; 1.32x fewer registers
Interpretation: GPU-centric I/O needs asynchronous progress and cache management as a unified library contract.
Reusable lesson: Separate submission from completion and dedicate device-local progress so application warps never hold blocking resources.
Applicability: Out-of-core DLRM, graph, and data-analytics workloads using GPU-direct SSD access.
Limits: Requires GPU-direct NVMe and software-managed HBM; gains require overlapable work. +
Bibliographic paper record. +
Verification: arXiv abstract, official DOI metadata, and author publication page; confidence=high.
Canonical title: AGILE: Lightweight and Efficient Asynchronous GPU-SSD Integration
Question: Can GPU threads issue SSD I/O asynchronously without deadlock while using HBM as a flexible software cache?
Context: Prior GPU-centric NVMe paths are synchronous, stalling threads during device latency.
Method: AGILE provides GPU-native asynchronous requests with deadlock-safe progress and a configurable HBM software cache.
Evaluation: workloads=CTC micro/workloads, DLRM, graph applications; baselines=synchronous GPU I/O and BaM; metrics=performance, API overhead, register use; results=1.88x; 1.75x vs BaM; 3.12x/2.85x lower overhead; 1.32x fewer registers
Interpretation: GPU-centric I/O needs asynchronous progress and cache management as a unified library contract.
Reusable lesson: Separate submission from completion and dedicate device-local progress so application warps never hold blocking resources.
Applicability: Out-of-core DLRM, graph, and data-analytics workloads using GPU-direct SSD access.
Limits: Requires GPU-direct NVMe and software-managed HBM; gains require overlapable work. +
정본 Lesson 보강 근거. 검토 원본: Lesson:technical_review_an_adaptive_zone_grouping_scheme_enabling_general_purpose_file_systems_on_zns_s_21d78705. 확인 범위: official_abstract. 확인한 자료: https://yonsei.elsevierpure.com/en/publications/an-adaptive-zone-grouping-scheme-enabling-general-purpose-file-sy/ ; https://doi.org/10.1145/3688351.3689151. 질문, 방법, 평가, 해석, 재사용 교훈, 적용 범위와 한계를 같은 Lesson 본문에 통합했습니다. +
Source: Yonsei University Computer Systems Laboratory publication list supplied by the user. Manifestation 1 of 1. +
Bibliographic paper record. +
Verification: official Microsoft Research publication page and DOI metadata; confidence=high.
Canonical title: An Empirical Study on Low GPU Utilization of Deep Learning Jobs
Question: What causes persistently low GPU utilization in real deep-learning jobs, and how often is it fixable?
Context: Low utilization is commonly blamed on hardware or framework limits, but production causes were not systematically classified.
Method: The study inspects 400 real jobs at or below 50% utilization, analyzes 706 issues, and applies targeted code/script fixes.
Evaluation: workloads=400 real jobs and 706 diagnosed issues; BERT and Swin case studies; baselines=original job implementations; metrics=GPU utilization, cause frequency, speedup; results=46.03% data; 45.18% model; 84.99% small-fixable; 7.52x/3.95x speedups
Interpretation: Most low utilization is an actionable software-pipeline problem rather than an immutable GPU limit.
Reusable lesson: Profile input, model, and synchronization paths before buying more accelerators.
Applicability: Production DL training/inference pipelines with unexpectedly low device occupancy.
Limits: The sample comes from one internal platform and deliberately selects low-utilization jobs. +
Verification: official Microsoft Research publication page and DOI metadata; confidence=medium.
Canonical title: An Empirical Study on Low GPU Utilization of Deep Learning Jobs
Question: What causes persistently low GPU utilization in real deep-learning jobs, and how often is it fixable?
Context: Low utilization is commonly blamed on hardware or framework limits, but production causes were not systematically classified.
Method: The study inspects 400 real jobs at or below 50% utilization, analyzes 706 issues, and applies targeted code/script fixes.
Evaluation: workloads=400 real jobs and 706 diagnosed issues; BERT and Swin case studies; baselines=original job implementations; metrics=GPU utilization, cause frequency, speedup; results=46.03% data; 45.18% model; 84.99% small-fixable; 7.52x/3.95x speedups
Interpretation: Most low utilization is an actionable software-pipeline problem rather than an immutable GPU limit.
Reusable lesson: Profile input, model, and synchronization paths before buying more accelerators.
Applicability: Production DL training/inference pipelines with unexpectedly low device occupancy.
Limits: The sample comes from one internal platform and deliberately selects low-utilization jobs. +