원격 데이터, 현재 CPU의 실행
2026년 5월의 v4 per-CPU work 제안은 대상 CPU의 자료를 보호하는 잠금을 사용해 호출 CPU에서 일부 작업을 직접 수행하는 경로를 제시합니다. 원격 CPU를 깨워서 그 CPU의 worker가 처리하도록 맡기는 경로와 구별해야 합니다. 자료의 소유 CPU가 곧 명령을 실행하는 CPU라는 가정은 성립하지 않습니다.
기존 경로: 대상 CPU에 work를 예약하고 완료를 기다립니다.
제안 경로: 대상 데이터의 잠금을 확보하고 호출 CPU에서 처리합니다.
검증 지점: 동기화, 캐시 이동, 실행 문맥과 최악 지연을 따로 측정합니다.
PREEMPT_RT의 local_lock을 단순 busy spin으로 설명하지 않습니다
local_lock은 non-RT 구성에서 preemption 또는 IRQ 제어의 범위를 이름으로 표현하고 lockdep 검사를 돕습니다. PREEMPT_RT에서는 per-CPU spinlock_t에 매핑되며 잠금의 동작도 RT 규칙을 따릅니다. 원격 데이터에 접근할 수 있도록 바꾸는 설계에는 같은 자료를 읽고 쓰는 모든 경로의 잠금 규약 검토가 필요합니다.
확인한 구현은 workqueue 경로를 유지합니다
2026-10-26의 Linux d135ab453a74에서 mm/folio.c의 __lru_add_drain_all()은 로컬 drain과 세대·동기화 처리를 수행하고, 필요한 CPU에 queue_work_on()을 호출한 뒤 예약한 작업을 flush_work()로 기다립니다. 이 경로를 이미 per-CPU work 제안으로 교체된 것처럼 설명할 근거는 없습니다.
CONFIG_PWLOCKS와 제안의 성능 수치는 해당 패치와 실험 조건에 속합니다. 모든 workqueue 호출이 반드시 IPI 하나를 발생시킨다거나, 모든 per-CPU 접근이 무료로 빨라진다고 일반화하지 않습니다. 실제 채택 여부는 정확한 리비전과 적용 패치를 기준으로 확인해야 합니다.
코드를 대조했다고 실시간 성능이 검증된 것은 아닙니다
여기서 확인한 범위는 제안의 커버 메일, 잠금 문서, 고정 리비전의 관련 소스입니다. 제안 전체 패치를 적용하거나 PREEMPT_RT 장비에서 지연을 측정하지 않았습니다. 채택 판단에는 처리량뿐 아니라 경쟁이 생길 때의 지연, CPU 격리, 캐시 이동과 종료 경로까지 확인해야 합니다.