실시간 우선순위( chrt -f 99)로 프로세스를 실행하면 단점이 있나요?
내 가설은 이것이 선호도와 결합되어 내 프로세스의 선점이 최소화되어 지터(특히 네트워크 대기 시간)가 최소화된다는 것입니다. 이는 전체 대기 시간에 도움이 되지 않지만 지금은 더 걱정됩니다. 지터 관련.
(커널: 2.6.16/3.0)
답변1
실시간 프로세스 실행의 가장 즉각적인 단점은 프로세스가 시스템의 다른 모든 프로세스를 쉽게 중단시킬 수 있다는 것입니다. 사용자의 관점에서 볼 때 실시간 프로세스가 CPU를 사용하는 한 컴퓨터는 키보드, 마우스 또는 네트워크에 전혀 응답하지 않게 됩니다. 문제가 발생하여 프로세스가 무한 루프에 빠지거나 프로세스가 정기적으로 입력을 기다리지 않고 장기 실행 계산을 시작하는 경우에도 이런 일이 발생할 수 있습니다. (예를 들어 실시간 우선순위로 SETI@home을 실행하지 마십시오.)
멀티 코어 CPU의 별도 단일 스레드 프로세스에서는 우선 순위가 낮은 프로세스가 다른 코어를 사용할 수 있으므로 이 문제가 발생할 가능성이 거의 없습니다. 그러나 프로세스가 하위 프로세스를 생성하는 경우 동일한 실시간 우선순위를 상속하므로 주의하지 않으면 상황이 통제되지 않을 수 있습니다.
이것sched_setscheduler(2)매뉴얼 페이지에는 좋은 조언이 있습니다.
SCHED_FIFO 또는 SCHED_RR에 예약된 프로세스의 비차단 무한 루프는 우선 순위가 낮은 모든 프로세스를 영원히 차단하므로 소프트웨어 개발자는 항상 콘솔을 테스트 대상 애플리케이션보다 높은 정적 우선 순위로 유지해야 합니다. 예약된 셸을 사용할 수 있습니다. 이를 통해 예상대로 차단되거나 종료되지 않는 테스트된 라이브 애플리케이션을 긴급 종료할 수 있습니다. getrlimit(2)의 RLIMIT_RTTIME 자원 제한에 대한 설명도 참조하세요.
그건 껍질이어야 해콘솔에서-- 모든 X에 실시간 우선순위를 부여하려는 경우가 아니면 Xterm에서는 사용할 수 없습니다.