컨텍스트 전환 시간 - RTOS 및 프로세서의 역할

Question

RTOS가 컨텍스트 전환 시간을 결정하는 데 중요한 역할을합니까? 컨텍스트 전환 시간을 결정할 때이 두 주요 플레이어 간의 점유율 비율은 얼마입니까?

누구나 uC/OS-II RTOS와 관련하여 말할 수 있습니까?

Answer 1

나는 모두가 중요하지만 그와 같은 정말 간단하지 않습니다 말할 것이다 :

실제 컨텍스트 스위치 시간은 단순히 소프트웨어에서 아무것도처럼 스위치를 수행하는 데 필요한 명령 사이클의 수의 문제입니다 효율적으로 코딩 될 수도 있고 그렇지 않을 수도 있습니다. 다른 한편으로, 다른 모든 것들이 동일하다면, 레지스터 세트가 큰 프로세서는 컨텍스트를 저장하기 위해 더 많은 명령 사이클을 필요로 할 것이다. 레지스터 세트가 커지면 다른 코드가 훨씬 더 효율적으로 작동 할 수 있습니다.

프로세서에는 빠른 컨텍스트 스위칭을 직접 지원하는 아키텍처가있을 수도 있습니다. 예를 들어 낮은 8bit 8051에는 4 개의 중복 레지스터 뱅크가 있습니다. 컨텍스트 스위치는 레지스터 뱅크 전환 (레지스터가 4 개 이상은 안되는 한)이며 Silicon Labs는 8051 기반 장치를 100MIPS로 생산하므로 실제로는 매우 빠를 수 있습니다!

더 정교한 프로세서와 운영 체제는 스레드 메모리 보호 기능을 제공하기 위해 MMU를 사용할 수 있습니다. 이것은 추가 컨텍스트 스위치 오버 헤드이지만 이점을 무시할 수 있습니다. 또한 물론 이러한 프로세서는 일반적으로 높은 클럭 속도를 가지고있어 도움이됩니다.

따라서 프로세서 속도, 프로세서 아키텍처, RTOS 구현의 품질 및 RTOS가 제공하는 기능은 모두 컨텍스트 전환 시간에 영향을 미칠 수 있습니다. 그러나 결국 스위치 시간을 개선하는 가장 쉬운 방법은 거의 확실하게 클럭 속도를 증가시키는 것입니다.

더 많은 헤드 룸을 갖는 것이 좋지만, 평판 좋은 RTOS에서 컨텍스트 전환 시간이 프로젝트에 대한 단서 또는 문제 일 경우 하드웨어 또는 디자인의 적합성을 고려해야합니다. 컨텍스트 전환을 최소화하는 디자인을 목표로해야합니다. 예를 들어, ADC 변환이 6us이고 컨텍스트 스위치가 20us가 걸리면 변환 완료 인터럽트를 사용하는 것보다 busy-wait를 사용하는 것이 좋습니다. 가능한 경우 단일 데이터 항목의 컨텍스트 전환을 피하기 위해 DMA 전송을 사용하는 것이 좋습니다.

Answer 2

uC/OS-II RTOS는 C로 작성되었으며, 프로세서 특정 처리를 위해 매우 특정한 일부 섹션 (어셈블리에있을 수도 있음)이 있습니다. 컨텍스트 스위칭은 프로세서에 매우 특정한 섹션의 일부입니다.

컨텍스트 전환 시간은 선택한 프로세서와 uC/OS-II를 해당 프로세서에 적용하는 데 사용되는 특정 섹션에 따라 크게 달라질 수 있습니다. 모든 소스 코드를 사용할 수 있으므로 컨텍스트 전환에 필요한 소스의 양을 확인할 수 있어야합니다. 또한 uC/OS-II에는 성능 측정 코드를 추가 할 수있는 콜백이 있다고 생각합니다.

Answer 3

Clifford가 말한 것을 완료하기 위해 컨텍스트 전환 시간은 컨텍스트 전환을 트리거하는 조건에 따라 달라 지므로 주로 벤치 마크에 따라 다릅니다.

RTOS 구현에 따라 경우에 따라 스케줄러를 우회하는 첫 번째 대기 프로세스로 직접 전환 할 수도 있습니다.

물론 이것은 일부 벤치 마크에서 엄청난 향상을 가져옵니다. http://www.bertos.org/discover/context-switch-overhead