Hacker News 의견

• QNX 마이크로커널의 장점

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

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

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

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

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

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

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

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

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

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

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

• 동기 로깅의 문제점

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

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

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

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

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

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

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