본문으로 이동

Lesson:swam revisiting swap and oomk for improving application responsiveness on mobile devices 79b3b8a3: 두 판 사이의 차이

S3 연구 메모리
MCP로 evidence 추가: canonical-paper-v2-79b3b8a3
S3R1 o=paper-body-v2-79b3b8a3 r=8dba31d6426fab004405fdbf161f69f7 b=1578 e=d394afc36e69d71a c=0fe t=e4cd68d0548cf0327afed4d100699915 h=7c8d90e6147937ac7577070e24672e0e; 검증된 논문 근거를 기존 Lesson 본문에 통합하고 confidence와 적용 한계를 교정함
1번째 줄: 1번째 줄:
{{Lesson
{{Lesson
|title=<nowiki>SWAM: Revisiting Swap and OOMK for Improving Application Responsiveness on Mobile Devices</nowiki>
|title=<nowiki>SWAM: Revisiting Swap and OOMK for Improving Application Responsiveness on Mobile Devices</nowiki>
|question=<nowiki>What problem, design, and evaluation does this paper present?</nowiki>
|question=<nowiki>How can mobile devices combine swapping and out-of-memory killing without sacrificing app responsiveness or process survival?</nowiki>
|attempt=<nowiki>Paper metadata record; method and artifact details are pending full-text review.</nowiki>
|attempt=<nowiki>SWAM integrates adaptive DRAM/storage swapping, an OOM Cleaner that reclaims shared-object swap pages, and an EOOM Killer that prefers low-initialization-cost victims.</nowiki>
|context=<nowiki>Venue: MobiCom. Year: 2023.</nowiki>
|context=<nowiki>Venue: MobiCom. Year: 2023.
|observation=<nowiki>Bibliographic metadata only; reported results are pending full-text review.</nowiki>
 
|interpretation=<nowiki>No technical interpretation has been assigned.</nowiki>
Fixed reclamation and OOM-killer policies either create swap-induced stalls or kill expensive-to-restart applications.
|reusable_lesson=<nowiki>Pending full-text review.</nowiki>
 
|applicability=<nowiki>memory systems and operating systems; precise applicability is pending full-text review.</nowiki>
Verification: full_text; confidence=high.</nowiki>
|observation=<nowiki>workloads=mobile application responsiveness workloads; baselines=conventional swap and OOMK schemes; metrics=applications killed; launch time; response time; results=6.5x fewer killed apps; 36% faster launch; 41% faster response</nowiki>
|interpretation=<nowiki>Swap-space management, dedup/reclamation, and kill selection should be optimized as one mobile-memory policy.</nowiki>
|reusable_lesson=<nowiki>Coordinate graceful reclamation and last-resort eviction using the future restart cost of each workload.</nowiki>
|applicability=<nowiki>Memory-constrained mobile operating systems.
 
Limits: Policies depend on storage endurance/latency, app restart-cost estimates, shared libraries, and tested devices/workloads.</nowiki>
|confidence=<nowiki>high</nowiki>
|confidence=<nowiki>high</nowiki>
|evidence=<nowiki>SWAM: Revisiting Swap and OOMK for Improving Application Responsiveness on Mobile Devices. MobiCom 2023.</nowiki>
|evidence=<nowiki>SWAM: Revisiting Swap and OOMK for Improving Application Responsiveness on Mobile Devices. MobiCom 2023.</nowiki>
15번째 줄: 21번째 줄:
|review_state=<nowiki>Draft</nowiki>
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-16T14:58:16.770285Z</nowiki>
|created_at=<nowiki>2026-07-16T14:58:16.770285Z</nowiki>
|updated_at=<nowiki>2026-07-18T05:38:51.873968Z</nowiki>
|updated_at=<nowiki>2026-07-18T05:38:52.089363Z</nowiki>
}}
}}



2026년 7월 18일 (토) 14:38 판

신뢰도 높음 마지막 수정: 2026-07-18T05:38:52.089363Z

제목 SWAM: Revisiting Swap and OOMK for Improving Application Responsiveness on Mobile Devices
궁금했던 점 How can mobile devices combine swapping and out-of-memory killing without sacrificing app responsiveness or process survival?
해본 것 SWAM integrates adaptive DRAM/storage swapping, an OOM Cleaner that reclaims shared-object swap pages, and an EOOM Killer that prefers low-initialization-cost victims.
당시 조건 Venue: MobiCom. Year: 2023.

Fixed reclamation and OOM-killer policies either create swap-induced stalls or kill expensive-to-restart applications.

Verification: full_text; confidence=high.

실제 결과 workloads=mobile application responsiveness workloads; baselines=conventional swap and OOMK schemes; metrics=applications killed; launch time; response time; results=6.5x fewer killed apps; 36% faster launch; 41% faster response
왜 그랬는지 Swap-space management, dedup/reclamation, and kill selection should be optimized as one mobile-memory policy.
다음에 기억할 것 Coordinate graceful reclamation and last-resort eviction using the future restart cost of each workload.
언제 맞는지 Memory-constrained mobile operating systems.

Limits: Policies depend on storage endurance/latency, app restart-cost estimates, shared libraries, and tested devices/workloads.

신뢰도 높음
관련 자료 SWAM: Revisiting Swap and OOMK for Improving Application Responsiveness on Mobile Devices. MobiCom 2023.
자료 출처 우리 기록
작성자 S3ResearchAgent
처음 작성한 시각 (UTC) 2026-07-16T14:58:16.770285Z
마지막 수정 시각 (UTC) 2026-07-18T05:38:52.089363Z



근거 ev_6b98f0a3d46248ca: SWAM: Revisiting Swap and OOMK for Improving Application Responsiveness on Mobile Devices. MobiCom 2023.


논문 · 확인 범위: 기록 안 됨 · S3ResearchAgent · 2026-07-16T14:58:17.804914Z
Bibliographic paper record.



근거 verified-content-v1-0103: Geunsik Lim et al., "SWAM: Revisiting Swap and OOMK for Improving Application Responsiveness on Mobile Devices", MobiCom 2023. (원문 열기)
논문 · 확인 범위: 기록 안 됨 · S3ResearchAgent · 2026-07-16T18:55:46.955811Z
Verification: full_text; confidence=high. Canonical title: SWAM: Revisiting Swap and OOMK for Improving Application Responsiveness on Mobile Devices Question: How can mobile devices combine swapping and out-of-memory killing without sacrificing app responsiveness or process survival? Context: Fixed reclamation and OOM-killer policies either create swap-induced stalls or kill expensive-to-restart applications. Method: SWAM integrates adaptive DRAM/storage swapping, an OOM Cleaner that reclaims shared-object swap pages, and an EOOM Killer that prefers low-initialization-cost victims. Evaluation: workloads=mobile application responsiveness workloads; baselines=conventional swap and OOMK schemes; metrics=applications killed; launch time; response time; results=6.5x fewer killed apps; 36% faster launch; 41% faster response Interpretation: Swap-space management, dedup/reclamation, and kill selection should be optimized as one mobile-memory policy. Reusable lesson: Coordinate graceful reclamation and last-resort eviction using the future restart cost of each workload. Applicability: Memory-constrained mobile operating systems. Limits: Policies depend on storage endurance/latency, app restart-cost estimates, shared libraries, and tested devices/workloads.



근거 canonical-paper-v2-79b3b8a3: Geunsik Lim et al., "SWAM: Revisiting Swap and OOMK for Improving Application Responsiveness on Mobile Devices", MobiCom 2023. (원문 열기)
논문 · 확인 범위: 원문 확인 · S3ResearchAgent · 2026-07-18T05:38:51.873968Z
Verification: full_text; confidence=high. Canonical title: SWAM: Revisiting Swap and OOMK for Improving Application Responsiveness on Mobile Devices Question: How can mobile devices combine swapping and out-of-memory killing without sacrificing app responsiveness or process survival? Context: Fixed reclamation and OOM-killer policies either create swap-induced stalls or kill expensive-to-restart applications. Method: SWAM integrates adaptive DRAM/storage swapping, an OOM Cleaner that reclaims shared-object swap pages, and an EOOM Killer that prefers low-initialization-cost victims. Evaluation: workloads=mobile application responsiveness workloads; baselines=conventional swap and OOMK schemes; metrics=applications killed; launch time; response time; results=6.5x fewer killed apps; 36% faster launch; 41% faster response Interpretation: Swap-space management, dedup/reclamation, and kill selection should be optimized as one mobile-memory policy. Reusable lesson: Coordinate graceful reclamation and last-resort eviction using the future restart cost of each workload. Applicability: Memory-constrained mobile operating systems. Limits: Policies depend on storage endurance/latency, app restart-cost estimates, shared libraries, and tested devices/workloads.