속성:Evidence note
자료에서 확인할 수 있는 점이나 한계를 적습니다.
m
mitigating resource usage dependency in sorting based kv stores on hybrid storage devices via op 31cbb8ad +
Verification: official USENIX page and abstract; confidence=medium.
Canonical title: Mitigating Resource Usage Dependency in Sorting-based KV Stores on Hybrid Storage Devices via Operation Decoupling
Question: Can LSM key-value stores reduce compaction and CPU coupling by managing indexes separately from values?
Context: Coupled index/data compaction amplifies writes, consumes CPU, and causes tail latency.
Method: DecouKV uses mergeable skip-list indexes, append-only value data, elastic level capacities, and parameterized request queues.
Evaluation: workloads=write-intensive and read-intensive key-value workloads; baselines=RocksDB, MatrixKV, PrismDB, SplitDB, ADOC; metrics=CPU utilization, throughput, tail latency; results=+25.4–32.3% CPU utilization; 2.3–4.9x write throughput; 74.3–91.4% lower tail; 1.2–2.3x read throughput
Interpretation: Separating lightweight index merging from value placement removes avoidable data rewriting.
Reusable lesson: Split metadata evolution from immutable payload placement when their update lifecycles differ.
Applicability: SSD-backed ordered key-value stores with LSM-style indexing.
Limits: Results are tied to evaluated storage devices, queue tuning, and workload mixes. +
Verification: full_text; confidence=high.
Canonical title: MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters
Question: Can DDR5 per-row activation counting and ALERT back-off be implemented with provable RowHammer security and low overhead?
Context: PRAC+ABO specifies mechanisms, not a secure policy; Panopticon's queue can be manipulated by crafted activation patterns.
Method: MOAT uses an eligibility threshold for proactive mitigation, an ALERT threshold for ABO, highest-count row tracking, and safe counter reset around refresh.
Evaluation: workloads=SPEC CPU; GAP graph workloads; Jailbreak and performance attacks; baselines=Panopticon; PRAC+ABO configurations; metrics=maximum aggressor activations; safe TRH; slowdown; SRAM overhead; results=Panopticon reaches 1,150 activations at threshold 128; MOAT ATH=64 safe for TRH=99; 0.28% average slowdown; 7 bytes SRAM per bank
Interpretation: Accurate per-row counters are insufficient unless queue service, delayed alerts, and reset semantics are included in the security proof.
Reusable lesson: Prove the complete mitigation state machine against adversarial scheduling, including backpressure and counter reset.
Applicability: DDR5 PRAC/ABO RowHammer mitigation designs.
Limits: Security bound depends on timing and threshold assumptions; evaluation is simulation/workload based and must track JEDEC/device implementation details. +
Bibliographic paper record. +
Verification: full_text; confidence=high.
Canonical title: MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters
Question: Can DDR5 per-row activation counting and ALERT back-off be implemented with provable RowHammer security and low overhead?
Context: PRAC+ABO specifies mechanisms, not a secure policy; Panopticon's queue can be manipulated by crafted activation patterns.
Method: MOAT uses an eligibility threshold for proactive mitigation, an ALERT threshold for ABO, highest-count row tracking, and safe counter reset around refresh.
Evaluation: workloads=SPEC CPU; GAP graph workloads; Jailbreak and performance attacks; baselines=Panopticon; PRAC+ABO configurations; metrics=maximum aggressor activations; safe TRH; slowdown; SRAM overhead; results=Panopticon reaches 1,150 activations at threshold 128; MOAT ATH=64 safe for TRH=99; 0.28% average slowdown; 7 bytes SRAM per bank
Interpretation: Accurate per-row counters are insufficient unless queue service, delayed alerts, and reset semantics are included in the security proof.
Reusable lesson: Prove the complete mitigation state machine against adversarial scheduling, including backpressure and counter reset.
Applicability: DDR5 PRAC/ABO RowHammer mitigation designs.
Limits: Security bound depends on timing and threshold assumptions; evaluation is simulation/workload based and must track JEDEC/device implementation details. +
Bibliographic paper record. +
Verification: full_text; confidence=high.
Canonical title: MoE-Lightning: High-Throughput MoE Inference on Memory-constrained GPUs
Question: How can large MoE models achieve high batch throughput on GPUs too small to hold their expert weights?
Context: Offloading is dominated by hierarchical CPU/GPU/I/O bottlenecks and poor overlap among expert weight transfer, compute, and KV state.
Method: MoE-Lightning uses CGOPipe CPU-GPU-I/O pipelining with paged weights and a Hierarchical Roofline Model to choose higher-throughput placement/schedules.
Evaluation: workloads=Mixtral 8x7B on one T4 16 GB; Mixtral 8x22B; DBRX; 2–4 low-cost GPUs; baselines=state-of-the-art offloading systems; FlexGen; metrics=throughput; CPU memory; resource utilization; results=up to 10.3x throughput; throughput bound with 2–3x less CPU memory
Interpretation: A hierarchy-aware analytic model can choose paging and overlap plans that saturate the true bottleneck.
Reusable lesson: Model every tier's roofline, then pipeline transfers and compute to the limiting resource.
Applicability: Batch MoE inference on low-cost, memory-constrained GPUs.
Limits: Optimized for batch throughput; results depend on model routing, batch size, I/O tiers, and T4/L4-class systems. +
Verification: full_text; confidence=high.
Canonical title: MoE-Lightning: High-Throughput MoE Inference on Memory-constrained GPUs
Question: How can large MoE models achieve high batch throughput on GPUs too small to hold their expert weights?
Context: Offloading is dominated by hierarchical CPU/GPU/I/O bottlenecks and poor overlap among expert weight transfer, compute, and KV state.
Method: MoE-Lightning uses CGOPipe CPU-GPU-I/O pipelining with paged weights and a Hierarchical Roofline Model to choose higher-throughput placement/schedules.
Evaluation: workloads=Mixtral 8x7B on one T4 16 GB; Mixtral 8x22B; DBRX; 2–4 low-cost GPUs; baselines=state-of-the-art offloading systems; FlexGen; metrics=throughput; CPU memory; resource utilization; results=up to 10.3x throughput; throughput bound with 2–3x less CPU memory
Interpretation: A hierarchy-aware analytic model can choose paging and overlap plans that saturate the true bottleneck.
Reusable lesson: Model every tier's roofline, then pipeline transfers and compute to the limiting resource.
Applicability: Batch MoE inference on low-cost, memory-constrained GPUs.
Limits: Optimized for batch throughput; results depend on model routing, batch size, I/O tiers, and T4/L4-class systems. +
정본 Lesson 보강 근거. 검토 원본: Lesson:technical_review_mp_bcoz_4fde17b0. 확인 범위: official_abstract. 확인한 자료: https://www.riss.kr/search/Search.do?colName=re_a_kor&isDetailSearch=Y&queryText=znCreator%2C%EA%B9%80%EB%AF%BC%EC%A4%80%28MinJun+Kim%29&searchGubun=true ; 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. +
n
Bibliographic paper record. +
Verification: official USENIX page and abstract; confidence=medium.
Canonical title: NanoFlow: Towards Optimal Large Language Model Serving Throughput
Question: How close can LLM serving get to hardware-optimal throughput by overlapping compute, memory, and network work inside each GPU?
Context: Request batching alone leaves device resources idle because Transformer operations stress different resources at different times.
Method: NanoFlow forms nano-batches, duplicates selected operators, and automatically chooses count, size, order, and resource allocation for overlap.
Evaluation: workloads=LLaMA-2-70B, Mixtral-8x7B, LLaMA-3-8B; baselines=state-of-the-art LLM serving systems and analytical optimum; metrics=serving throughput and percent of optimum; results=up to 1.91x; 50–72% of optimum
Interpretation: Intra-device scheduling is as important as request scheduling for high-throughput serving.
Reusable lesson: Co-schedule operations with complementary bottlenecks at a granularity below the request batch.
Applicability: GPU LLM serving with predictable operator profiles.
Limits: May duplicate work and requires model/hardware-specific profiling and scheduling. +
Verification: official USENIX page and abstract; confidence=high.
Canonical title: NanoFlow: Towards Optimal Large Language Model Serving Throughput
Question: How close can LLM serving get to hardware-optimal throughput by overlapping compute, memory, and network work inside each GPU?
Context: Request batching alone leaves device resources idle because Transformer operations stress different resources at different times.
Method: NanoFlow forms nano-batches, duplicates selected operators, and automatically chooses count, size, order, and resource allocation for overlap.
Evaluation: workloads=LLaMA-2-70B, Mixtral-8x7B, LLaMA-3-8B; baselines=state-of-the-art LLM serving systems and analytical optimum; metrics=serving throughput and percent of optimum; results=up to 1.91x; 50–72% of optimum
Interpretation: Intra-device scheduling is as important as request scheduling for high-throughput serving.
Reusable lesson: Co-schedule operations with complementary bottlenecks at a granularity below the request batch.
Applicability: GPU LLM serving with predictable operator profiles.
Limits: May duplicate work and requires model/hardware-specific profiling and scheduling. +
정본 Lesson 보강 근거. 검토 원본: Lesson:technical_review_nap_natural_app_processing_for_predictive_user_contexts_in_mobile_smartphones_df34aff8. 확인 범위: full_text. 확인한 자료: https://www.mdpi.com/2076-3417/10/19/6657 ; https://doi.org/10.3390/app10196657. 질문, 방법, 평가, 해석, 재사용 교훈, 적용 범위와 한계를 같은 Lesson 본문에 통합했습니다. +
Source: Yonsei University Computer Systems Laboratory publication list supplied by the user. Manifestation 1 of 1. +
Verification: full_text; confidence=high.
Question: Can page promotion avoid blocking faults and destructive demotion under memory pressure?
Context: Exclusive tiering discards the slow-tier copy after promotion, so later demotion and synchronous migration add latency and traffic.
Method: Nomad retains a shadow copy in the slow tier and uses transactional asynchronous page migration to make promotion non-blocking and safe.
Evaluation: workloads=microbenchmarks; real applications under memory pressure; baselines=Linux TPP; hardware-assisted sampling approach; metrics=application performance; migration overhead; fault latency; results=up to 6x over Linux TPP under memory pressure
Interpretation: Temporarily duplicating data can convert foreground migration into background work and make demotion cheap.
Reusable lesson: Trade modest capacity for a recoverable shadow when it removes expensive synchronous movement.
Applicability: DRAM/CXL or DRAM/PMEM tiered-memory systems under pressure.
Limits: Shadow pages consume slow-tier capacity and require transactional coherence; gains vary with pressure and reuse. +
Verification: full_text; confidence=high.
Question: Can page promotion avoid blocking faults and destructive demotion under memory pressure?
Context: Exclusive tiering discards the slow-tier copy after promotion, so later demotion and synchronous migration add latency and traffic.
Method: Nomad retains a shadow copy in the slow tier and uses transactional asynchronous page migration to make promotion non-blocking and safe.
Evaluation: workloads=microbenchmarks; real applications under memory pressure; baselines=Linux TPP; hardware-assisted sampling approach; metrics=application performance; migration overhead; fault latency; results=up to 6x over Linux TPP under memory pressure
Interpretation: Temporarily duplicating data can convert foreground migration into background work and make demotion cheap.
Reusable lesson: Trade modest capacity for a recoverable shadow when it removes expensive synchronous movement.
Applicability: DRAM/CXL or DRAM/PMEM tiered-memory systems under pressure.
Limits: Shadow pages consume slow-tier capacity and require transactional coherence; gains vary with pressure and reuse. +
Bibliographic paper record. +
not a dpu in name only unleashing rdma capable dpus in multi tenant serverless clouds with nadin 7031318c +
Verification: official DOI/publisher abstract and EuroSys program; confidence=high.
Canonical title: Not A DPU in Name Only! Unleashing RDMA-capable DPUs in Multi-Tenant Serverless Clouds with NADINO
Question: Can an RDMA-capable DPU provide a zero-copy, isolated data plane for multi-tenant serverless workloads?
Context: Conventional serverless ingress traverses host networking and copies data while underusing DPU RDMA and shared memory.
Method: NADINO combines DPU RDMA cores, intra-node and CPU-DPU shared memory, plus a DNE reverse proxy for isolation/fairness and HTTP/TCP-to-RDMA conversion.
Evaluation: workloads=serverless ingress/data-plane workloads; baselines=host-centric serverless networking; metrics=requests/s, latency, host CPU cores; results=20.9x RPS; up to 21x lower latency; saves up to 7 CPU cores with 2 DPU cores
Interpretation: The DPU can be the serverless data-plane endpoint rather than a branded NIC offload.
Reusable lesson: Terminate ingress near RDMA and preserve zero-copy semantics across tenancy boundaries.
Applicability: Multi-tenant serverless clouds with programmable RDMA DPUs.
Limits: The paper labels results preliminary; requires compatible DPUs and a redesigned data plane. +
not a dpu in name only unleashing rdma capable dpus in multi tenant serverless clouds with nadin 7031318c +
Verification: official DOI/publisher abstract and EuroSys program; confidence=medium.
Canonical title: Not A DPU in Name Only! Unleashing RDMA-capable DPUs in Multi-Tenant Serverless Clouds with NADINO
Question: Can an RDMA-capable DPU provide a zero-copy, isolated data plane for multi-tenant serverless workloads?
Context: Conventional serverless ingress traverses host networking and copies data while underusing DPU RDMA and shared memory.
Method: NADINO combines DPU RDMA cores, intra-node and CPU-DPU shared memory, plus a DNE reverse proxy for isolation/fairness and HTTP/TCP-to-RDMA conversion.
Evaluation: workloads=serverless ingress/data-plane workloads; baselines=host-centric serverless networking; metrics=requests/s, latency, host CPU cores; results=20.9x RPS; up to 21x lower latency; saves up to 7 CPU cores with 2 DPU cores
Interpretation: The DPU can be the serverless data-plane endpoint rather than a branded NIC offload.
Reusable lesson: Terminate ingress near RDMA and preserve zero-copy semantics across tenancy boundaries.
Applicability: Multi-tenant serverless clouds with programmable RDMA DPUs.
Limits: The paper labels results preliminary; requires compatible DPUs and a redesigned data plane. +
not a dpu in name only unleashing rdma capable dpus in multi tenant serverless clouds with nadin 7031318c +
Bibliographic paper record. +