속성:Evidence note
자료에서 확인할 수 있는 점이나 한계를 적습니다.
s
Bibliographic paper record. +
Verification: abstract_only; confidence=high.
Canonical title: Scalable and Effective Page-table and TLB management on NUMA Systems
Question: NUMA에서 페이지표 지역성과 TLB shootdown 확장성을 동시에 개선할 수 있는가?
Context: eager 전체 복제는 page walk를 지역화하지만 page-table update와 shootdown을 더 비싸게 한다.
Method: Hydra는 투명한 on-demand partial replication과 정확한 sharer 추적으로 불필요한 TLB shootdown을 줄인다.
Evaluation: workloads=4- and 8-socket x86_64; Webserver; Memcached; memory-management microbenchmarks; baselines=baseline Linux; eager full page-table replication; metrics=runtime; TLB shootdowns; memory-management overhead; results=12% Webserver and 36% Memcached runtime improvement; up to 40× baseline overhead characterized.
Interpretation: 페이지표 공유 범위를 정확히 알면 읽기 지역성과 업데이트 확장성의 충돌을 완화할 수 있다.
Reusable lesson: NUMA 메타데이터 복제는 전체 복제보다 수요 기반 부분 복제와 sharer 추적을 사용하라.
Applicability: 대형 멀티소켓 Linux 서버.
Limits: x86_64 4·8 socket 평가이며 sharer 메타데이터·Linux 변경 비용이 있다. +
Verification: abstract_only; confidence=medium.
Canonical title: Scalable and Effective Page-table and TLB management on NUMA Systems
Question: NUMA에서 페이지표 지역성과 TLB shootdown 확장성을 동시에 개선할 수 있는가?
Context: eager 전체 복제는 page walk를 지역화하지만 page-table update와 shootdown을 더 비싸게 한다.
Method: Hydra는 투명한 on-demand partial replication과 정확한 sharer 추적으로 불필요한 TLB shootdown을 줄인다.
Evaluation: workloads=4- and 8-socket x86_64; Webserver; Memcached; memory-management microbenchmarks; baselines=baseline Linux; eager full page-table replication; metrics=runtime; TLB shootdowns; memory-management overhead; results=12% Webserver and 36% Memcached runtime improvement; up to 40× baseline overhead characterized.
Interpretation: 페이지표 공유 범위를 정확히 알면 읽기 지역성과 업데이트 확장성의 충돌을 완화할 수 있다.
Reusable lesson: NUMA 메타데이터 복제는 전체 복제보다 수요 기반 부분 복제와 sharer 추적을 사용하라.
Applicability: 대형 멀티소켓 Linux 서버.
Limits: x86_64 4·8 socket 평가이며 sharer 메타데이터·Linux 변경 비용이 있다. +
Bibliographic paper record. +
Bibliographic paper record. +
Verification: official_abstract; confidence=medium.
Canonical title: Scalable Billion-point Approximate Nearest Neighbor Search Using SmartSSDs
Question: How can billion-point ANN search scale beyond host memory while using SmartSSD compute and bandwidth efficiently?
Context: Host-only search is capacity/bandwidth limited; naive computational-storage partitioning wastes device work and data movement.
Method: SmartANNS combines host/SmartSSD hierarchical indexes, dynamic task scheduling, data reuse, and learned shard pruning.
Evaluation: workloads=billion-scale ANN datasets; commercial Samsung SmartSSDs; baselines=CSDANNS; metrics=QPS; recall; multi-SSD scalability; results=up to 10.7x QPS; near-linear scaling
Interpretation: Near-data ANN needs coordinated indexing, pruning, and scheduling, not simple operator offload.
Reusable lesson: Partition both the search space and control plane across host and near-data compute.
Applicability: Large vector-search services using computational storage.
Limits: Depends on SmartSSD hardware, learned pruning accuracy, index configuration, and evaluated datasets. +
Verification: official_abstract; confidence=high.
Canonical title: Scalable Billion-point Approximate Nearest Neighbor Search Using SmartSSDs
Question: How can billion-point ANN search scale beyond host memory while using SmartSSD compute and bandwidth efficiently?
Context: Host-only search is capacity/bandwidth limited; naive computational-storage partitioning wastes device work and data movement.
Method: SmartANNS combines host/SmartSSD hierarchical indexes, dynamic task scheduling, data reuse, and learned shard pruning.
Evaluation: workloads=billion-scale ANN datasets; commercial Samsung SmartSSDs; baselines=CSDANNS; metrics=QPS; recall; multi-SSD scalability; results=up to 10.7x QPS; near-linear scaling
Interpretation: Near-data ANN needs coordinated indexing, pruning, and scheduling, not simple operator offload.
Reusable lesson: Partition both the search space and control plane across host and near-data compute.
Applicability: Large vector-search services using computational storage.
Limits: Depends on SmartSSD hardware, learned pruning accuracy, index configuration, and evaluated datasets. +
Verification: official DOI metadata and author-lab publication abstract; confidence=high.
Canonical title: Scalable Far Memory: Balancing Faults and Evictions
Question: How can page-based far memory scale fault-in and eviction on many-core machines?
Context: Holistic coordination creates TLB-shootdown, page-accounting, and allocation bottlenecks as thread count rises.
Method: The work applies always-asynchronous eviction, cross-batch pipelining, and scalability-first coordination in Linux and a library OS.
Evaluation: workloads=batch applications and latency-critical Memcached; baselines=existing page-based far-memory coordination; metrics=throughput and p99 latency; results=up to 4.2x throughput; 94.5% lower p99
Interpretation: Slightly less precise eviction can be worthwhile when synchronization otherwise destroys scalability.
Reusable lesson: Decouple and pipeline opposing memory flows, prioritizing scalable progress over perfect victim selection.
Applicability: Page-based remote/far memory on high-core-count servers.
Limits: Trades eviction accuracy for concurrency; results depend on far-memory latency and thread count. +
Verification: official DOI metadata and author-lab publication abstract; confidence=medium.
Canonical title: Scalable Far Memory: Balancing Faults and Evictions
Question: How can page-based far memory scale fault-in and eviction on many-core machines?
Context: Holistic coordination creates TLB-shootdown, page-accounting, and allocation bottlenecks as thread count rises.
Method: The work applies always-asynchronous eviction, cross-batch pipelining, and scalability-first coordination in Linux and a library OS.
Evaluation: workloads=batch applications and latency-critical Memcached; baselines=existing page-based far-memory coordination; metrics=throughput and p99 latency; results=up to 4.2x throughput; 94.5% lower p99
Interpretation: Slightly less precise eviction can be worthwhile when synchronization otherwise destroys scalability.
Reusable lesson: Decouple and pipeline opposing memory flows, prioritizing scalable progress over perfect victim selection.
Applicability: Page-based remote/far memory on high-core-count servers.
Limits: Trades eviction accuracy for concurrency; results depend on far-memory latency and thread count. +
Bibliographic paper record. +
Verification scope: official USENIX OSDI 2022 paper page/abstract; confidence=medium.
Research question: How can a private cloud distribute large, hot objects at very high fanout while supporting diverse per-use-case policies?
Context: Meta needed one distribution service for millions of client processes and heterogeneous workloads.
Method: Owl combines ephemeral peer-to-peer distribution trees in a decentralized data plane with centralized tracker services. Trackers maintain peer/cache/download metadata, choose fetch sources and retries, control caching/eviction, and expose a configurable policy interface; peers remain simple state machines.
Evaluation/results: USENIX reports more than 800 PB distributed per day, 2–3× faster downloads than BitTorrent and Meta’s prior decentralized static tree, and production support for 106 use cases using 55 policies.
Interpretation: Centralizing control decisions need not prevent data-plane scalability when bulk transfer remains peer-to-peer.
Applicability/limits: Most directly applicable to high-fanout object distribution inside a managed private cloud. The official abstract does not establish equivalent behavior on open or adversarial networks. +
Bibliographic paper record. +
Verification scope: official USENIX OSDI 2022 paper page/abstract.
Research question: How can a private cloud distribute large, hot objects at very high fanout while supporting diverse per-use-case policies?
Context: Meta needed one distribution service for millions of client processes and heterogeneous workloads.
Method: Owl combines ephemeral peer-to-peer distribution trees in a decentralized data plane with centralized tracker services. Trackers maintain peer/cache/download metadata, choose fetch sources and retries, control caching/eviction, and expose a configurable policy interface; peers remain simple state machines.
Evaluation/results: USENIX reports more than 800 PB distributed per day, 2–3× faster downloads than BitTorrent and Meta’s prior decentralized static tree, and production support for 106 use cases using 55 policies.
Interpretation: Centralizing control decisions need not prevent data-plane scalability when bulk transfer remains peer-to-peer.
Applicability/limits: Most directly applicable to high-fanout object distribution inside a managed private cloud. The official abstract does not establish equivalent behavior on open or adversarial networks. +
Verification: official_abstract; confidence=medium.
Canonical title: ScaleCache: A Scalable Page Cache for Multiple Solid-State Drives
Question: How can the Linux page cache scale with many fast SSDs and many CPU cores?
Context: Shared XArray operations and serialized writeback become bottlenecks before a multi-NVMe array is saturated.
Method: ScaleCache introduces concurrent ccXArray operations and dflush for parallel, opportunistic direct flushing.
Evaluation: workloads=file-system workloads on 64 cores and eight NVMe SSDs; baselines=Linux page cache; prior scalable page-cache scheme; metrics=file-system performance; scalability; writeback throughput; results=up to 6.81x over Linux; up to 4.50x over prior scalable scheme
Interpretation: Both cache metadata concurrency and writeback parallelism must scale with the device array.
Reusable lesson: Remove coordination bottlenecks from both the foreground index and background drain path.
Applicability: Linux file systems on multi-NVMe servers.
Limits: Results depend on the evaluated 64-core/eight-drive platform and altered page-cache/writeback semantics. +
Bibliographic paper record. +
Verification: official_abstract; confidence=high.
Canonical title: ScaleCache: A Scalable Page Cache for Multiple Solid-State Drives
Question: How can the Linux page cache scale with many fast SSDs and many CPU cores?
Context: Shared XArray operations and serialized writeback become bottlenecks before a multi-NVMe array is saturated.
Method: ScaleCache introduces concurrent ccXArray operations and dflush for parallel, opportunistic direct flushing.
Evaluation: workloads=file-system workloads on 64 cores and eight NVMe SSDs; baselines=Linux page cache; prior scalable page-cache scheme; metrics=file-system performance; scalability; writeback throughput; results=up to 6.81x over Linux; up to 4.50x over prior scalable scheme
Interpretation: Both cache metadata concurrency and writeback parallelism must scale with the device array.
Reusable lesson: Remove coordination bottlenecks from both the foreground index and background drain path.
Applicability: Linux file systems on multi-NVMe servers.
Limits: Results depend on the evaluated 64-core/eight-drive platform and altered page-cache/writeback semantics. +
Bibliographic paper record. +
Verification: official USENIX page and abstract; confidence=medium.
Canonical title: ScaleSwap: A Scalable OS Swap System for All-Flash Swap Arrays
Question: How can OS swap scale across many CPU cores and NVMe SSDs without shared metadata bottlenecks?
Context: Linux swap centralizes queues/LRU metadata and underutilizes parallel all-flash arrays.
Method: ScaleSwap assigns per-core swap resources, adds opportunistic inter-core metadata assistance, and maintains page/LRU affinity.
Evaluation: workloads=swap workloads on 128 cores and 8 NVMe SSDs; baselines=Linux, TMO, ExtMEM; metrics=throughput and average latency; results=up to 3.4x throughput and 11.5x lower latency vs Linux; +64% vs TMO; up to 5x ExtMEM
Interpretation: Swap must shard ownership by core while allowing bounded work sharing under imbalance.
Reusable lesson: Pair per-core fast paths with opportunistic assistance instead of global work queues.
Applicability: Large-memory-pressure servers backed by multi-NVMe swap arrays.
Limits: Targets large all-flash/128-core configurations; smaller systems may not expose the same contention. +
Verification: official USENIX page and abstract; confidence=high.
Canonical title: ScaleSwap: A Scalable OS Swap System for All-Flash Swap Arrays
Question: How can OS swap scale across many CPU cores and NVMe SSDs without shared metadata bottlenecks?
Context: Linux swap centralizes queues/LRU metadata and underutilizes parallel all-flash arrays.
Method: ScaleSwap assigns per-core swap resources, adds opportunistic inter-core metadata assistance, and maintains page/LRU affinity.
Evaluation: workloads=swap workloads on 128 cores and 8 NVMe SSDs; baselines=Linux, TMO, ExtMEM; metrics=throughput and average latency; results=up to 3.4x throughput and 11.5x lower latency vs Linux; +64% vs TMO; up to 5x ExtMEM
Interpretation: Swap must shard ownership by core while allowing bounded work sharing under imbalance.
Reusable lesson: Pair per-core fast paths with opportunistic assistance instead of global work queues.
Applicability: Large-memory-pressure servers backed by multi-NVMe swap arrays.
Limits: Targets large all-flash/128-core configurations; smaller systems may not expose the same contention. +
Bibliographic paper record. +