▲

GN⁺: 실시간 사전 차단의 최종 목표

 (lwn.net)
2P by neo 2023-11-17 | favorite | 댓글 1개

리눅스 실시간 선점 지원의 종착점

  • 리눅스에 실시간 지원을 추가하는 작업은 2004년부터 시작되었으며, 이제 마무리 단계에 접어듦.
  • 실시간 선점의 목적은 최고 우선순위 프로세스가 최소한의 지연으로 실행될 수 있도록 하는 것이며, 이를 위해 커널을 가능한 많은 상황에서 선점 가능하게 만듦.
  • 이 작업은 커널의 핵심 부분을 재작성하는 결과를 가져왔으며, 실시간 사용 사례를 넘어서는 혜택을 제공함.

printk() 문제의 해결

  • 커널에서 시스템 콘솔과 로그로 메시지를 보낼 때 사용하는 printk() 함수는 동기식으로 작동하여 모든 설정된 목적지로 메시지가 전송될 때까지 반환되지 않음.
  • 실시간 개발자들은 printk() 출력을 별도의 스레드로 이동시켜 비동기식으로 만들었지만, 이는 임시 해결책에 불과함.
  • 2018년부터 진지하게 작업되어온 printk() 문제는 약 300개의 패치를 통해 해결되어 가고 있으며, 아직 해결해야 할 몇 가지 복잡한 문제가 남아있음.

실시간 선점 코드의 메인라인 통합 전망

  • 실시간 선점 코드의 나머지 부분이 2024년 말 20주년이 되기 전에 메인라인에 통합될 것이라는 희망을 표현함.
  • printk() 코드에 대한 최근 변화는 없었으나, 콘솔 드라이버를 하나씩 업데이트할 수 있도록 핸드오버 코드가 변경되었음.
  • 중요한 메시지는 첫 번째 줄이 출력되기 전에 메시지 버퍼에 완전히 복사되도록 코드가 변경되었으며, 잘못된 콘솔 드라이버로 인한 시스템 다운을 방지하기 위해 안전한 콘솔에 먼저 메시지를 기록함.

GN⁺의 의견

  • 리눅스 커널에 실시간 선점 지원을 추가하는 작업은 거의 완료 단계에 있으며, 이는 실시간 작업을 필요로 하는 시스템에 큰 혜택을 제공할 것임.
  • printk() 함수의 비동기화는 시스템의 반응성을 향상시키고, 실시간 선점의 목표를 달성하는 데 중요한 역할을 함.
  • 이 기사는 리눅스 커널 개발의 중요한 진전을 보여주며, 커널 개발에 관심이 있는 사람들에게 흥미로운 내용을 제공함.
▲
neo 2023-11-17  [-]
Hacker News 의견

  • QNX 마이크로커널의 장점

    • QNX 마이크로커널은 수십 년 전부터 모든 작업에 상한선을 두어 신뢰성을 보장함.
    • 마이크로커널 코드는 수만 줄에 불과하며, 메모리 할당, CPU 디스패치, 프로세스 간 메시지 전달만 담당함.
    • 드라이버와 로거를 포함한 모든 기타 기능은 사용자 공간에 있어 높은 우선순위 스레드에 의해 선점될 수 있음.
    • QNX 커널은 문자열 작업을 전혀 하지 않아, 문자열 파싱, 포매팅, 메시지 전달에서 발생하는 문제가 없음.

  • 리눅스의 실시간 처리 문제

    • 리눅스는 실시간 처리에 적합하지 않은 구조로, 커널 코드가 수백만 줄에 달하며 모든 코드를 선점 가능하게 만들어야 함.
    • 실시간 아키텍처로서의 부적합성 때문에 이를 수정하는 데 수십 년이 걸림.
    • 커널 문제에만 초점을 맞추는 것은 CPU 수준의 문제를 간과하는 것일 수 있음.

  • 커널의 로깅 기능과 실제 사용 사례

    • 시스템이 다운되는 상황에서도 로그 메시지를 출력하기 위해 커널이 얼마나 노력하는지에 대한 예시가 실제 배포에서 어떻게 활용되는지 설명함.

  • 실시간 하드웨어/소프트웨어 조합의 대체 가능성

    • 실시간 처리가 필요한 하드웨어/소프트웨어 조합이 저렴하고, 저전력, 고클럭의 ARM 및 x86 칩으로 대체될 수 있는지에 대한 의문 제기.
    • 클럭 속도가 높아지면서 완벽한 실시간 처리의 중요성이 감소할 수 있음을 언급.

  • "하드" 대 "소프트" 실시간 애플리케이션의 구분

    • "하드" 실시간 애플리케이션에서는 리눅스와 같은 범용 OS를 사용하지 않는 것이 바람직함.
    • "소프트" 실시간 애플리케이션(예: 비디오컨퍼런싱, 오디오 재생)에서는 약간의 지연이나 프레임 손실이 큰 문제가 되지 않음.
    • 리눅스를 실시간 OS로 만들고자 하는 논의는 이미 가능한 "소프트" 실시간 사용 사례에 초점을 맞춤.
    • 커널을 완전히 선점 가능하게 만들고 스케줄링에 대한 제어를 높이는 것은 실시간 OS나 베어메탈 코드를 대체하려는 목적보다는 시스템의 건전한 관리에 더 큰 의미가 있음.

  • 리눅스 커널의 실시간 처리와 하드웨어의 한계

    • 리눅스 커널이 실시간 처리를 지원하더라도, 캐시와 CPU 내부의 복잡한 기능 때문에 하드웨어가 실시간을 지원하지 못할 수 있음.
    • 진정한 실시간 처리를 위해서는 복잡한 하드웨어 대신 단순한 CPU 아키텍처가 선호됨.

  • 동기 로깅의 문제점

    • GLOG(구글의 로깅 라이브러리)와 같은 동기 로깅이 디스크 I/O에 블록되어 서비스가 지연되는 문제를 경험함.

  • 특정 프로세스의 응답성 보장 방법

    • 특정 프로세스의 응답성을 중요시한다면, 해당 프로세스에 전용 CPU 코어와 연속된 메모리 영역을 할당하고, OS의 나머지 부분과 분리된 네트워크 카드에 직접 접근할 수 있도록 해야 함.

  • 리눅스의 실시간 선점 기능과 과거 경험

    • 과거에 리눅스 커널에 RT_PREEMPT 패치를 적용하여 과학 장비에 사용했던 경험과 그로 인해 개선된 지연 시간과 지터에 대한 인상을 공유함.

  • 일반 사용자에게 미치는 영향

    • 실시간 처리 기능이 일반 사용자에게 어떤 의미가 있는지, 특정 상황에서만 활성화할 것인지, 일반적인 시스템의 반응성 향상에도 도움이 될 수 있는지에 대한 질문 제기.
답변달기