실시간 우선 순위로 프로세스를 실행하는 데 부정적인 영향이 있습니까?

실시간 우선 순위 ( chrt -f 99) 로 실행중인 프로세스의 단점이 있습니까?

내 가설은 친화력과 결합하여 프로세스의 선점을 최소화하고 지터 (특히 네트워크 대기 시간)를 최소화 할 수 있다는 것입니다. 이는 전반적인 대기 시간에 도움이되지 않지만 지금은 더 많이 있습니다 지터와 관련이 있습니다.

(커널 : 2.6.16 / 3.0)

linux process real-time

— 님
소스

이것은 당신을 위해 도움이 보인다 : 어떻게 자바 지터를 줄이기 위해?

— ire_and_curses

@ire_and_curses, 현재 프로세스는 자체 격리 된 코어 (적어도 주요 처리 스레드)에서 실행되지만 인터럽트는 동일한 코어에서 예약되지 않습니다 (같은 네트워크 인터페이스에 의존하는 여러 유사한 프로세스가 있으므로 수행 할 수 없음) APIC 빈도는 흥미 롭습니다. 이전에 본 적이 없습니다.

— Nim

실시간 프로세스 실행의 가장 직접적인 단점은 프로세스가 시스템의 다른 모든 프로세스를 쉽게 고갈시킬 수 있다는 것입니다. 실시간 프로세스가 CPU를 사용하는 한 컴퓨터는 키보드, 마우스 및 네트워크에 완전히 응답하지 않습니다. 이는 문제가 발생하여 프로세스가 무한 루프 상태가되거나 프로세스가 주기적으로 입력을 기다리지 않고 장기 실행 계산을 시작하는 경우에도 발생할 수 있습니다. (예를 들어, 실시간 우선 순위로 SETI @ home을 실행하지 마십시오.)

우선 순위가 낮은 프로세스가 사용할 수있는 다른 코어가 있기 때문에 멀티 코어 CPU의 단일 스레드 프로세스는이 문제를 일으킬 가능성이 적습니다. 그러나 해당 프로세스가 하위 프로세스를 작성하면 동일한 실시간 우선 순위를 상속하므로주의하지 않으면 상황이 제어되지 않을 수 있습니다.

sched_setscheduler(2)매뉴얼 페이지 좋은 충고가 있습니다 :

SCHED_FIFO 또는 SCHED_RR에 따라 스케줄 된 프로세스의 비 차단 무한 루프는 우선 순위가 낮은 모든 프로세스를 영원히 차단하므로 소프트웨어 개발자는 항상 테스트 된 애플리케이션보다 높은 정적 우선 순위로 스케줄 된 쉘을 콘솔에서 항상 사용할 수 있어야합니다. 이를 통해 예상대로 차단되거나 종료되지 않는 테스트 된 실시간 응용 프로그램을 비상 종료 할 수 있습니다. getrlimit (2)의 RLIMIT_RTTIME 자원 제한에 대한 설명도 참조하십시오.

모든 X 실시간 우선 순위를 부여하지 않는 한 Xterm이 아닌 콘솔 의 쉘이어야합니다 .

— 얀더
소스

예-이것이 내가 겪는 주요 문제입니다. 우선 순위가 더 높은 모든 프로세스를 결정하기 위해 커널 코드를 읽지 못하는 유일한 방법은 내 프로세스에서 다른 모든 프로세스를 배제하고 모든 형태의 io를 필요로하는 모든 것을 다른 코어로 옮기는 것입니다 ... hmmm. ..

— Nim