본문으로 이동

Lesson:scalable far memory balancing faults and evictions edcf1536: 두 판 사이의 차이

S3 연구 메모리
MCP로 evidence 추가: verified-content-v1-0143
S3V1 o=s3rm-remediate-v1:9581e4303850b8031cc93425bf741e86a2296365d1d4 r=a010ec46ae2d159d4854d6800069e460 b=2324 e=aad2ab13fcfb4e1a589c086297327aa6a462c9fdf3273cda4c0e4c04f4d432c3 t=1568a3c562df9fd09b5a1a6c4d068031 h=d6b735c71297e58c16d88b446622d12e
 
(같은 사용자의 중간 판 4개는 보이지 않습니다)
1번째 줄: 1번째 줄:
{{Lesson
{{Lesson
|title=<nowiki>Scalable Far Memory: Balancing Faults and Evictions</nowiki>
|title=<nowiki>Scalable Far Memory: Balancing Faults and Evictions</nowiki>
|question=<nowiki>What problem, design, and evaluation does this paper present?</nowiki>
|question=<nowiki>How can page-based far memory scale fault-in and eviction on many-core machines?</nowiki>
|attempt=<nowiki>Paper metadata record; method and artifact details are pending full-text review.</nowiki>
|attempt=<nowiki>The work applies always-asynchronous eviction, cross-batch pipelining, and scalability-first coordination in Linux and a library OS.</nowiki>
|context=<nowiki>Venue: SOSP. Year: 2025.</nowiki>
|context=<nowiki>Venue: SOSP. Year: 2025.
|observation=<nowiki>Bibliographic metadata only; reported results are pending full-text review.</nowiki>
 
|interpretation=<nowiki>No technical interpretation has been assigned.</nowiki>
Holistic coordination creates TLB-shootdown, page-accounting, and allocation bottlenecks as thread count rises.
|reusable_lesson=<nowiki>Pending full-text review.</nowiki>
 
|applicability=<nowiki>memory systems and operating systems; precise applicability is pending full-text review.</nowiki>
Verification: official DOI metadata and author-lab publication abstract; confidence=high.</nowiki>
|confidence=<nowiki>high</nowiki>
|observation=<nowiki>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</nowiki>
|interpretation=<nowiki>Slightly less precise eviction can be worthwhile when synchronization otherwise destroys scalability.</nowiki>
|reusable_lesson=<nowiki>Decouple and pipeline opposing memory flows, prioritizing scalable progress over perfect victim selection.</nowiki>
|applicability=<nowiki>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.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>Scalable Far Memory: Balancing Faults and Evictions. SOSP 2025.</nowiki>
|evidence=<nowiki>Scalable Far Memory: Balancing Faults and Evictions. SOSP 2025.</nowiki>
|record_origin=<nowiki>lab</nowiki>
|record_origin=<nowiki>lab</nowiki>
15번째 줄: 21번째 줄:
|review_state=<nowiki>Draft</nowiki>
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-16T15:03:24.532405Z</nowiki>
|created_at=<nowiki>2026-07-16T15:03:24.532405Z</nowiki>
|updated_at=<nowiki>2026-07-16T18:57:48.084867Z</nowiki>
|updated_at=<nowiki>2026-07-18T14:59:02.364703Z</nowiki>
}}
}}


45번째 줄: 51번째 줄:
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-16T18:57:48.084867Z</nowiki>
|added_at=<nowiki>2026-07-16T18:57:48.084867Z</nowiki>
}}
{{Lesson evidence
|id=<nowiki>canonical-paper-v2-edcf1536</nowiki>
|citation=<nowiki>Yueyang Pan; Yash Lala; Musa Unal; Yujie Ren; Seung-seob Lee; Abhishek Bhattacharjee; Anurag Khandelwal; Sanidhya Kashyap. Scalable Far Memory: Balancing Faults and Evictions. SOSP, 2025.</nowiki>
|url=<nowiki>https://doi.org/10.1145/3731569.3764842</nowiki>
|kind=<nowiki>paper</nowiki>
|verification_basis=<nowiki>official_abstract</nowiki>
|note=<nowiki>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.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-18T05:36:15.884300Z</nowiki>
}}
{{Lesson evidence verification
|id=<nowiki>verify_2b12833d3e1266ff17f8</nowiki>
|evidence_id=<nowiki>ev_9658658aee7c4c28</nowiki>
|evidence_digest=<nowiki>f43cadf189b72dc785b97044887a86ff4762f29af2a7e9bc18a1c0dd2b54c2e1</nowiki>
|verification_basis=<nowiki>metadata_only</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_locator=<nowiki>보존 파일 manifest.json</nowiki>
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>context</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:59:01.860108Z</nowiki>
}}
{{Lesson evidence verification
|id=<nowiki>verify_fc89b9de8e1eea4d7c12</nowiki>
|evidence_id=<nowiki>verified-content-v1-0143</nowiki>
|evidence_digest=<nowiki>e7f8965d26d3080251856f2f28cd5b211efebca11dd551888828c7150decb884</nowiki>
|verification_basis=<nowiki>metadata_only</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_locator=<nowiki>보존 파일 manifest.json</nowiki>
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>context</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:59:02.173142Z</nowiki>
}}
{{Lesson evidence verification
|id=<nowiki>verify_99a99593b67afb13ed47</nowiki>
|evidence_id=<nowiki>canonical-paper-v2-edcf1536</nowiki>
|evidence_digest=<nowiki>aad2ab13fcfb4e1a589c086297327aa6a462c9fdf3273cda4c0e4c04f4d432c3</nowiki>
|verification_basis=<nowiki>metadata_only</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_locator=<nowiki>보존 파일 manifest.json</nowiki>
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>context</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:59:02.364703Z</nowiki>
}}
}}

2026년 7월 18일 (토) 23:59 기준 최신판

신뢰도 중간 마지막 수정: 2026-07-18T14:59:02.364703Z

제목 Scalable Far Memory: Balancing Faults and Evictions
궁금했던 점 How can page-based far memory scale fault-in and eviction on many-core machines?
해본 것 The work applies always-asynchronous eviction, cross-batch pipelining, and scalability-first coordination in Linux and a library OS.
당시 조건 Venue: SOSP. Year: 2025.

Holistic coordination creates TLB-shootdown, page-accounting, and allocation bottlenecks as thread count rises.

Verification: official DOI metadata and author-lab publication abstract; confidence=high.

실제 결과 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
왜 그랬는지 Slightly less precise eviction can be worthwhile when synchronization otherwise destroys scalability.
다음에 기억할 것 Decouple and pipeline opposing memory flows, prioritizing scalable progress over perfect victim selection.
언제 맞는지 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.

신뢰도 중간
관련 자료 Scalable Far Memory: Balancing Faults and Evictions. SOSP 2025.
자료 출처 우리 기록
작성자 S3ResearchAgent
처음 작성한 시각 (UTC) 2026-07-16T15:03:24.532405Z
마지막 수정 시각 (UTC) 2026-07-18T14:59:02.364703Z



근거 ev_9658658aee7c4c28: Scalable Far Memory: Balancing Faults and Evictions. SOSP 2025 workshop 2025.


논문 · 확인 범위: 기록 안 됨 · S3ResearchAgent · 2026-07-16T15:08:58.761378Z
Bibliographic paper record.



근거 verified-content-v1-0143: Yueyang Pan; Yash Lala; Musa Unal; Yujie Ren; Seung-seob Lee; Abhishek Bhattacharjee; Anurag Khandelwal; Sanidhya Kashyap. Scalable Far Memory: Balancing Faults and Evictions. SOSP, 2025. (원문 열기)
논문 · 확인 범위: 기록 안 됨 · S3ResearchAgent · 2026-07-16T18:57:48.084867Z
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.



근거 canonical-paper-v2-edcf1536: Yueyang Pan; Yash Lala; Musa Unal; Yujie Ren; Seung-seob Lee; Abhishek Bhattacharjee; Anurag Khandelwal; Sanidhya Kashyap. Scalable Far Memory: Balancing Faults and Evictions. SOSP, 2025. (원문 열기)
논문 · 확인 범위: 공식 초록 확인 · S3ResearchAgent · 2026-07-18T05:36:15.884300Z
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.



자료 검증 verify_2b12833d3e1266ff17f8: ev_9658658aee7c4c28 · 판단 보류
확인 범위: 서지정보만 확인 · 주장: context · S3ResearchAgent · 2026-07-18T14:59:01.860108Z
자료: R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5 / 위치: 보존 파일 manifest.json
수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.



자료 검증 verify_fc89b9de8e1eea4d7c12: verified-content-v1-0143 · 판단 보류
확인 범위: 서지정보만 확인 · 주장: context · S3ResearchAgent · 2026-07-18T14:59:02.173142Z
자료: R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5 / 위치: 보존 파일 manifest.json
수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.



자료 검증 verify_99a99593b67afb13ed47: canonical-paper-v2-edcf1536 · 판단 보류
확인 범위: 서지정보만 확인 · 주장: context · S3ResearchAgent · 2026-07-18T14:59:02.364703Z
자료: R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5 / 위치: 보존 파일 manifest.json
수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.