리눅스 커널에서 fork() + exec()를 넘어서려는 새 논의가 나옴

오래된 fork() + exec() 패턴이 다시 도마 위에 오름

• 리눅스에서 프로세스를 띄우는 고전 패턴은 fork()로 자식 프로세스를 만들고, 곧바로 exec()로 실행 파일을 바꾸는 방식임

  • fork()는 부모 프로세스의 메모리와 상태를 자식 쪽에 복사하는 비싼 시스템 호출임
  • 커널이 수년간 최적화를 많이 했지만, 구조적으로 “일단 복사하고 나중에 버리는” 비용은 남아 있음
  • 특히 fork() 직후 exec()가 오면, 애써 준비한 자식 프로세스 메모리 상태 대부분을 바로 폐기하게 됨

• 이번 패치셋은 이 반복 비용을 줄이려고 spawn template이라는 아이디어를 제안함

  • 예를 들어 어떤 프로그램이 Git 실행 파일을 반복 호출해서 저장소 정보를 읽는 상황을 상상하면 됨
  • 매번 같은 실행 파일을 띄운다면, 실행 파일 관련 준비 정보를 템플릿으로 만들어 캐시해두자는 접근임

spawn template이 하려던 일

• 제안된 API는 spawn_template_create()로 실행 파일 템플릿을 먼저 만드는 구조임

  • 실행 파일은 파일 디스크립터(execfd)나 절대 경로(filename) 중 하나로 지정함
  • 커널은 해당 실행 파일을 열고, 이후 더 빨리 실행하는 데 필요한 정보를 캐시함
  • 반환값은 템플릿을 가리키는 파일 디스크립터임

• 실제 실행 시점에는 spawn_template_spawn()에 인자와 환경, 파일 디스크립터 조작 같은 정보를 넘김

  • argv는 프로그램 인자 목록, envp는 환경 변수 목록임
  • actions에는 자식 프로세스에서 파일 디스크립터를 닫거나 복제하거나, 작업 디렉터리를 바꾸거나, 시그널 처리를 바꾸는 작업이 들어감
  • 예를 들어 자식에서 fd 4를 닫고 싶으면 SPAWN_TEMPLATE_ACTION_CLOSE와 fd 4를 액션에 넣는 식임

sequenceDiagram
    participant 앱 as 애플리케이션
    participant 커널 as 리눅스 커널
    participant 템플릿 as Spawn 템플릿
    participant 자식 as 새 프로세스
    앱->>커널: spawn_template_create()
    커널->>템플릿: 실행 파일 정보 캐시
    앱->>커널: argv, envp, actions 전달
    커널->>템플릿: 캐시된 실행 정보 조회
    커널->>자식: spawn_template_spawn()으로 실행

• 성능 개선은 약 2%로 제시됨
  • 숫자만 보면 “겨우?” 싶을 수 있음
  • 하지만 같은 실행 파일을 매우 자주 띄우는 워크로드라면 2%도 누적 비용에서는 의미가 있을 수 있음
  • 커널 패치 논의에서는 이런 작은 비용도 충분히 진지하게 다뤄짐

리뷰는 더 근본적인 방향으로 틀어짐

• Mateusz Guzik은 fork + exec 관용구 자체가 문제라고 강하게 지적함

  • spawn template은 exec 쪽 일부를 최적화하지만, 정작 비용의 큰 부분인 fork()는 그대로 둠
  • 그의 핵심 주장은 현재 프로세스를 복사하지 말고, 처음부터 깨끗한 새 프로세스를 만드는 방향으로 가야 한다는 것임

• Christian Brauner도 목표 자체에는 긍정적이었지만, API 방향은 pidfd 위에 쌓는 쪽을 제안함

  • pidfd_open()에 빈 프로세스를 만드는 옵션을 추가하는 식의 구상을 언급함
  • 이후 pidfd_config() 같은 새 시스템 호출로 환경, 실행 이미지, 설정을 단계적으로 구성하는 방식임
  • fsconfig()가 파일 시스템 설정을 빌더처럼 구성하는 것과 비슷한 발상으로 보면 됨

• 중요한 목표는 user space에서 제대로 된 posix_spawn()을 구현할 수 있게 하는 것임

  • posix_spawn()은 fork()/exec() 패턴을 대체하기 좋은 인터페이스임
  • 하지만 현재 구현은 내부적으로 fork()와 exec()를 감추는 경우가 많아서 근본적인 비용을 없애진 못함
  • 커널이 빈 프로세스 생성과 설정을 네이티브하게 지원하면, posix_spawn()이 진짜 대체재가 될 수 있음

• 결론적으로 spawn template 자체는 커널에 들어가지 않을 가능성이 커짐

  • 제안자인 Chen도 Brauner가 스케치한 pidfd 기반 API가 더 나은 방향이라는 데 동의함
  • 앞으로의 작업은 spawn template보다는 proper posix_spawn() 구현을 가능하게 하는 쪽으로 갈 전망임

기술 맥락

• 여기서 핵심 선택은 “기존 fork()/exec() 경로를 살짝 빠르게 만들 것인가, 프로세스 생성 모델을 새로 설계할 것인가”예요. spawn template은 앞쪽 선택에 가깝고, pidfd 기반 빈 프로세스 생성은 뒤쪽 선택에 가까워요.

• fork()가 비싼 이유는 새 프로그램을 실행하려는 순간에도 일단 현재 프로세스를 복제하는 모델에서 출발하기 때문이에요. copy-on-write 같은 최적화가 있어도, 커널이 다뤄야 하는 프로세스 상태와 검증 경로는 여전히 복잡하거든요.

• pidfd 기반 접근이 매력적인 이유는 프로세스를 파일 디스크립터처럼 안정적으로 붙잡고, 실행 이미지나 환경 같은 설정을 단계적으로 넣을 수 있기 때문이에요. 이렇게 되면 user space의 posix_spawn()이 fork()/exec()를 감춘 래퍼가 아니라, 커널 기능을 제대로 쓰는 인터페이스가 될 수 있어요.

• 이 변화는 셸 하나 빠르게 띄우는 수준보다 범위가 넓어요. Git을 반복 호출하는 도구, 빌드 시스템, 서버 런처처럼 프로세스를 자주 만드는 프로그램에서는 작은 시스템 호출 비용과 설계 차이가 전체 지연 시간에 계속 누적되거든요.