본문으로 건너뛰기

FDP 기여를 위한 발굴 아이템 (seed)

이 디렉토리의 최종 산출물. 근거는 ankit_base_commits.md / dev_baseline_status.md / mp_integration_gap.md / policy_proposals.md.

모든 아이템은 검증 필요 / 결정 필요 표시를 둠. PoC 환경에서 1차 확인 후 task 인덱스(tasks/)로 승격.

1. 작업 흐름 (사용자 합의 재확인)​

  1. 히스토리 파악 — ankit#1 8커밋 해부 ✅ (ankit_base_commits.md)
  2. 현재 status 파악 — origin/dev FDP 표면 ✅ (dev_baseline_status.md)
  3. 현재 아키텍처 기준 status — MP gap ✅ (mp_integration_gap.md)
  4. FDP PoC로 효과 입증 + 아이템 발굴 — ← 지금 이 문서
  5. 기여 — 발굴된 아이템을 PR-A~PR-E 분할안에 매핑

01_branch_audit/03_fdp_implementation_audit.md §5의 PR 분할안:

  • PR-A (대): 5개 config + _select_fdp_ruh/_write_directive_for_ruh + Rust dtype/dspec + validate_nvme_directive
  • PR-B: ankit#1의 fetch_fdp_status 자동 조회 통합
  • PR-C: metadata RUH 분리 (WAF 효과 입증 후)
  • PR-D: file backend FDP (write hint or io_uring_cmd 공유)
  • PR-E (선택): FDP WAF stress harness

2. 발굴 아이템 — 효과 입증 트랙​

I-E1. data/metadata RUH 분리의 WAF 정량 효과 측정 [효과 입증]​

근거: ankit#1 2be75bb5에서 이미 hardcode — "due to their distinct lifetimes" 라는 정성적 진술만 있음. 해야 할 일: benchmarks/fdp_waf_stress/ mode separated vs mixed 측정으로 WAF 차이 정량화. 기여 단위: PR-C 보강 데이터 (이미 03_audit에서 식별된 단위). 검증 필요: WAF 측정 자체보다, dongdongju PoC와 ankit#1의 "분리 모드" 정의가 같은지 — PoC는 fdp_metadata_mode="per_ruh" (별도 RUH list), ankit#1은 "default RUH 사용" (FDP directive 안 붙임). 두 방식의 의미적 차이 확인. 선행: 단계 4 측정 환경 가용성.

I-E2. 정책 ① rank isolation 효과 측정 (MP setup) [효과 입증]​

근거: MP에서 per_tp_device_paths 거부 → FDP placement_id가 isolation 유일 수단 (policy_proposals.md §1). baseline: policy_proposals.md §5 매트릭스 B1 vs R. 측정 지표: per-rank read/write throughput, RU 점유 분포, p99 latency. 검증 필요: rank 수 > RUH 수일 때 fallback 정책 (round-robin? hash? rank>>group?). 기여 단위: PR-A의 하위 (정책 abstraction의 첫 구현체).

I-E3. 정책 ②③ access pattern 근거 자료 정리 [선행]​

근거: daegyu 진술 — "상윤/나연님이 정리하신 자료 보고 근거를 만들려고". 해야 할 일: 사용자가 보유한 model별·tenant별 KV cache access pattern 자료를 정리해 PoC 실험 가설로 변환. 산출: 이 contribution/ 디렉토리에 access_pattern_evidence.md 신설 (현 plan 범위 밖, 후속). 검증 필요: 자료가 어디에 있는지 (사용자 확인 필요).

I-E4. dongdongju PoC를 MP setup에 실제로 돌려보기 [검증]​

근거: 사용자 진술 — "아마도 fdp poc 코드는 mp mode에서 동작하는 거로 되어있긴할거야". 해야 할 일: PoC의 RawBlockCore FDP 코드가 RawBlockL2Adapter를 통해 호출되는 경로 실증 (trace). 검증 필요: PoC의 _select_fdp_ruh 3단 fallback이 MP의 ThreadPoolExecutor store 경로에서 어떻게 호출되는지 — obj.metadata.fdp_placement_rank stamping 주체가 누구인지 (lmcache/v1/multiprocess/server.py:34). 선행: 단계 3 build/test 환경.

3. 발굴 아이템 — 코드/구조 보강 트랙​

I-C1. MP adapter 경로에 FDP placement_id surface 추가 [신규 PR 후보]​

근거: ankit#1의 in-process plugin 변경분이 MP adapter에는 0% 반영됨 (dev_baseline_status.md §1). 해야 할 일:

  • RawBlockL2AdapterConfig에 use_fdp + fdp_data_ruh_ids + fdp_metadata_mode 등 추가 (mp_integration_gap.md §5).
  • RawBlockCore.put_many() 시그니처 또는 RawBlockKeySpec에 placement hint 통로 추가.
  • ankit#1의 _fetch_fdp_status/_get_data_placement_id/_build_data_placement_ids 재사용. 검증 필요: 시그니처 확장이 다른 caller (dax_backend 등)에 영향 주는지. 기여 단위: 새 PR (03_audit PR-A 분할안과 별개, MP 확장 단위).

I-C2. ankit#1의 fail-fast가 MP에서 같이 작동하는지 확인 [검증]​

근거: ankit#1 _configure_fdp_placements에서 status 빈 응답 → RuntimeError. 해야 할 일: MP adapter __init__에서 같은 fail-fast 흐름 가능한지 (worker process 시작 시점 실패 처리). 검증 필요: MP에서 worker_id 가져오는 시점이 RawBlockCore init보다 늦으면 어떻게 처리? 기여 단위: I-C1과 묶임.

I-C3. PlacementPolicy 추상화 vs caller stamp 결정 [설계]​

근거: 03_audit (a) gap — "PoC는 harness가 storage_class별 RUH list를 stamp, ankit#1은 plugin 안에서 결정. upstream 시 어느 쪽?" 옵션:

  • (A) PlacementPolicy interface를 core에 두고 plugin이 주입 — 정책 ②③ 확장 용이
  • (B) 정책 결정은 caller (L1/scheduler)가 하고 ObjectKey metadata로 stamp — core 단순 forward
  • (C) 두 layer 모두 (default policy + override hint) 검증 필요: dongdongju PoC가 (B)를 채택한 이유 — harness 확장성 / core 단순화. 기여 단위: PR-A의 설계 결정. 이 결정은 effort estimate 이전에 daegyu와 합의 필요.

I-C4. ankit#1의 fetch_fdp_status 자동 조회를 dongdongju PoC에 합류 [상위 머지]​

근거: dongdongju PoC가 RUH descriptor 자동 조회 미포함, ankit#1만의 강점 (03_audit §3 PR-B 후보). 해야 할 일: ankit#1 머지 후, dongdongju 측 코드가 fetch_fdp_status 사용하도록 통합. 기여 단위: PR-B (이미 식별됨).

4. 발굴 아이템 — 운영/관측 트랙​

I-O1. FDP 관측 지표 추가 [신규]​

근거: ankit#1에 FDP 관련 metric 없음, dongdongju harness만 보유 (offline). 해야 할 일 (03_audit (f) gap 참조):

  • WAF (write amplification factor) — vendor counter 의존
  • RU utilization per PID
  • placement_id distribution histogram
  • failed FDP directive count 기여 단위: B1 텔레메트리 (tasks/index.md v2 B1)와 합류 가능. 또는 별도 PR. 검증 필요: vendor counter 접근 방법 (smartctl? nvme-cli? sysfs?).

I-O2. CLI flag 노출 [운영 편의]​

근거: 03_audit (g) gap — YAML/JSON config로만 가능. 해야 할 일: lmcache storage configure --use-fdp --data-ruhs 0,1,2,3 --metadata-ruhs 4 같은 CLI 노출. 기여 단위: 03_audit PR-A 후속 / 작은 PR.

5. 우선순위 (initial guess — daegyu와 합의 후 확정)​

순서아이템이유
1I-E4 (PoC를 MP에 실제로 돌리기)다른 모든 작업의 전제
2I-E1 (data/metadata RUH 분리 WAF 측정)ankit#1 hardcode를 정당화 / PR-C 데이터
3I-C3 (PlacementPolicy 추상 vs caller stamp 결정)I-C1의 설계 결정. daegyu와 합의 필요
4I-C1 (MP adapter FDP surface)실제 기여의 main 단위
5I-E2 (rank isolation 측정)정책 정당화 데이터
6I-C4 (fetch_fdp_status 통합)ankit#1 머지 후
7I-O1 (관측 지표)운영 도입 시점에
후순위I-E3 (access pattern 자료), I-C2 (fail-fast 검증), I-O2 (CLI)기반 작업 후

6. 미해결 사용자 입력 필요 항목​

  • daegyu와 머지 경로 정렬 (ankit#1을 본 레포로 가져갈 일정 / 우리가 그 위에 stacked PR로 갈지)
  • dongdongju PoC가 MP mode 기준으로 동작하는지 실증 (I-E4)
  • access pattern 근거 자료 위치 / 요약 (I-E3)
  • PlacementPolicy 추상화 방향 결정 (I-C3)