eventfd 는 ID 가 아니다

변경 검증 가이드 (다음 fetch 후):

git log eaa2bfee..HEAD -- lmcache/v1/distributed/l2_adapters/raw_block_l2_adapter.py
git log eaa2bfee..HEAD -- private/docs/notes/raw_block_line.md

위에 커밋이 잡히면 store/lookup/load 3 개 분리가 유지되는지 (개수/이름 바뀌면 "eventfd 3 개 분리" 섹션 갱신), MP adapter 가 eventfd 가 아닌 다른 알림 메커니즘으로 갈아탔다면 본 메모 "왜 쓰는가" 섹션부터 다시 써야 함.

---

정의

리눅스 커널이 만들어주는 특수한 파일 디스크립터(file descriptor).

• 일반 파일 fd 처럼 정수 하나 (예: fd=7)
• 하지만 파일을 읽고 쓰는 게 아니라 "신호 카운터" 역할
• man 2 eventfd 가 공식 문서

int efd = eventfd(0, 0);   // 커널이 새 신호 통로를 만들어서 fd 번호를 줌

작동 방식

eventfd 는 내부적으로 8 바이트 카운터 하나를 들고 있음:

[커널]
  카운터: 0
  ↑
  ├── write(efd, 1) → 카운터 += 1   (= "이벤트 발생!" 신호)
  └── read(efd)     → 카운터 값 반환 + 0 으로 리셋  (= "신호 받음")

• 카운터가 0: read 하면 블록(잠듦)
• 카운터가 0 이상: read 하면 즉시 깨어나서 카운터 값 받음

→ 한쪽이 write 하면 반대쪽이 read 에서 깨어남. 이게 알림 메커니즘.

왜 쓰는가

[LMCache 서버]                  [vLLM 프로세스]
  store 작업 끝!
  write(store_efd, 1)  ────────►  poll(store_efd) 에서 깨어남
                                   read(store_efd)
                                   pop_completed_store_tasks()

• poll / select / epoll 로 여러 fd 를 한꺼번에 기다릴 수 있음 → 소켓, 타이머, eventfd 다 같이 감시
• 프로세스가 달라도 fd 만 공유하면 통신 가능
• 메시지 내용은 없음 — "뭔가 일어났다" 만 알림 (내용은 별도 큐/공유메모리)

"eventfd 3 개 분리" 의 의미

raw_block_line.md:65 가 말하는 것:

eventfd 3 개 분리 (store / lookup / load)

= 커널에 신호 통로 3 개를 따로 만들어서:

• store_efd (fd=7 같은 정수)
• lookup_efd (fd=8)
• load_efd (fd=9)

각각 다른 일이 끝났을 때 다른 통로로 알림.

ID 와 어떻게 다른가

항목	ID (예: task_id)	eventfd
무엇	작업을 식별하는 숫자/문자열	신호를 주고받는 통로
누가 만드나	애플리케이션 코드 (예: uuid4())	리눅스 커널 (eventfd() 시스템콜)
용도	"어떤 작업인지" 구분	"뭔가 끝났다"고 깨우기
비유	영수증 번호	진동벨/도어벨

LMCache 는 둘 다 씀:

• task_id (애플리케이션 ID): 어떤 store 요청인지 구분 → 결과 dict 의 키
• eventfd (커널 신호): "store 결과가 있다" 고 vLLM 깨우기

깨어난 vLLM 은 task_id 로 dict 를 조회해서 자기가 던진 요청의 결과를 가져감.

한 줄

eventfd = 리눅스 커널이 주는 "깨우기 전용 fd" — ID 가 아니라 통신/동기화용 통로 자체.