RHEL for Real Time 이해

실시간 프로세서 코어는 물리적 CPU(중앙 처리 장치)이며 시스템 코드를 실행합니다. 소켓은 컴퓨터의 프로세서와 마더보드 간 연결입니다. 소켓은 프로세서가 배치되는 마더보드의 위치입니다. 두 가지 프로세서 세트가 있습니다.

실시간 환경을 설계할 때는 사용 가능한 코어 수, 코어 간 캐시 레이아웃, 코어가 물리적으로 연결된 방식을 알고 있어야 합니다.

여러 코어를 사용할 수 있는 경우 스레드 또는 프로세스를 사용합니다. 이러한 구성을 사용하지 않고 작성된 프로그램은 한 번에 단일 프로세서에서 실행됩니다. 멀티 코어 플랫폼은 다양한 유형의 운영에 서로 다른 코어를 사용할 때 이점을 제공합니다.

tuna CLI(명령줄 도구)를 사용하면 캐시 레이아웃을 결정하고 상호 작용 스레드를 코어에 바인딩하여 캐시를 공유할 수 있습니다. 캐시 공유는 상호 제외 기본(mutex, 조건 변수 또는 유사)와 데이터 구조가 동일한 캐시를 사용하도록 하여 메모리 오류를 줄입니다.

많은 하드웨어 벤더들이 이제 NUMA(Non-Uniform Memory Access) 아키텍처로 알려진 코어와 메모리 간의 투명한 상호 연결 네트워크를 제공합니다.

NUMA는 멀티프로세싱에 사용되는 시스템 메모리 설계로, 메모리 액세스 시간은 프로세서와 관련된 메모리 위치에 따라 달라집니다. NUMA를 사용하면 프로세서는 다른 프로세서의 메모리 또는 프로세서 간에 공유되는 메모리와 같이 로컬이 아닌 메모리보다 더 빠르게 자체 로컬 메모리에 액세스할 수 있습니다. NUMA 시스템에서 상호 연결 토폴로지를 이해하면 인접한 코어에서 자주 통신하는 스레드를 배치할 수 있습니다.

taskset 및 numactl 유틸리티는 CPU 토폴로지를 결정합니다. taskset 은 메모리 노드와 같은 NUMA 리소스 없이 CPU 선호도를 정의하고 numactl 은 프로세스 및 공유 메모리에 대한 NUMA 정책을 제어합니다.

수요 페이징은 페이지 스와핑이 있는 페이징 시스템과 유사합니다. 시스템은 필요한 경우 또는 CPU 요구에 따라 보조 메모리에 저장된 페이지를 로드합니다. 프로그램에서 생성된 모든 메모리 주소는 프로세서의 주소 변환 메커니즘을 통과합니다. 그러면 주소가 프로세스별 가상 주소에서 실제 메모리 주소로 변환됩니다. 이를 가상 메모리라고 합니다. 변환 메커니즘의 두 가지 주요 구성 요소는 페이지 테이블 및 변환 조회 버퍼(TLB)입니다.

할당된 물리적 주소를 가진 페이지 테이블 항목을 상주 작업 세트라고 합니다. 운영 체제가 다른 프로세스의 메모리를 해제해야 하는 경우 상주 작업 집합에서 페이지를 스왑할 수 있습니다. 페이지를 스와핑할 때 해당 페이지 내의 가상 주소에 대한 참조로 페이지 폴트가 생성되고 페이지가 재할당됩니다.

시스템이 물리적 메모리에서 매우 낮으면 스왑 프로세스가 중단되기 시작하여 프로세스에서 페이지를 지속적으로 훔치고 프로세스를 완료할 수 없습니다. /proc/vmstat 파일에서 pgfault 값을 확인하여 가상 메모리 통계를 모니터링할 수 있습니다.

TLB는 참조의 지역성 원칙에 따라 작동합니다. 즉, 코드가 상당한 기간 동안 메모리의 한 영역에 남아 있으면 (예: 루프 또는 호출 관련 기능) TLB 참조는 주소 변환의 주요 메모리를 사용하지 않습니다. 이는 처리 시간을 크게 가속화할 수 있습니다.

결정적 및 빠른 코드를 작성할 때 참조의 현지성을 유지하는 함수를 사용합니다. 이는 재귀 대신 루프를 사용하는 것을 의미할 수 있습니다. 재귀를 피할 수 없는 경우 함수 끝에 재귀 호출을 배치합니다. 이를 tail-recursion이라고 하며, 이를 통해 비교적 작은 메모리 영역에서 코드가 작동하고 기본 메모리에서 테이블 번역을 호출하는 것을 방지할 수 있습니다.

RHEL for Real Time은 물리적 메모리를 페이지라는 청크로 분할한 다음 가상 메모리에 매핑하여 메모리를 할당합니다. 프로세스에서 매핑되지 않았거나 더 이상 메모리에서 사용할 수 없는 특정 페이지가 필요한 경우 실시간으로 오류가 발생합니다. 따라서 오류는 기본적으로 CPU에 필요한 경우 페이지를 사용할 수 없음을 의미합니다. 프로세스가 페이지 폴트가 발생하면 커널이 이 오류를 처리할 때까지 모든 스레드가 중지됩니다. 이 문제를 해결하는 방법에는 여러 가지가 있지만 가장 좋은 해결책은 페이지 오류를 피하기 위해 소스 코드를 조정하는 것입니다.

실시간으로 애플리케이션에 성능 저하가 표시되면 /proc/ 디렉토리에서 페이지 폴트와 관련된 프로세스 정보를 확인하는 것이 좋습니다. cat 명령을 사용하여 특정 PID(프로세스 ID)의 경우 다음과 같은 관련 항목에 대해 /proc/PID/stat 파일을 볼 수 있습니다.

다음 예제에서는 /proc/PID/stat 파일의 두 번째, 10번째 및 twelfth 행만 반환하는 cat 명령과 pipe 함수로 페이지 폴트를 보는 방법을 보여줍니다.

# cat /proc/3366/stat | cut -d\ -f2,10,12
  (bash) 5389 0

예제 출력에서 PID 3366이 있는 프로세스는 bash이며 5389 마이너 페이지 폴트와 주요 페이지 폴트가 없습니다.

메모리 잠금(mlock()) 시스템 호출을 사용하면 프로세스를 호출하여 지정된 주소 공간 범위를 잠그거나 잠금 해제하여 Linux가 잠긴 메모리를 스왑 공간으로 페이징하지 못하도록 합니다. 페이지 테이블 항목에 실제 페이지를 할당한 후에는 해당 페이지에 대한 참조가 상대적으로 빠릅니다. 메모리 잠금 시스템 호출은 mlock() 및 munlock() 카테고리로 분류됩니다.

mlock() 및 munlock() 시스템은 잠금을 호출하고 지정된 프로세스 주소 페이지의 범위를 잠금 해제합니다. 성공하면 munlock() 시스템 호출이 페이지를 잠금 해제할 때까지 지정된 범위의 페이지가 메모리에 남아 있습니다.

mlock() 및 munlock() 시스템 호출에는 다음과 같은 매개변수가 필요합니다.

성공하면 mlock() 및 munlock() 시스템 호출은 0을 반환합니다. 오류가 발생하면 -1을 반환하고 오류를 나타내기 위해 errno 를 설정합니다.

mlockall() 및 munlockall() 시스템 호출은 모든 프로그램 공간을 잠금 또는 잠금 해제합니다.

메모리 잠금은 페이지 기반으로 생성되며 스택되지 않습니다. 동적으로 할당된 두 개의 메모리 세그먼트가 mlock() 또는 mlockall() 에 의해 두 번 잠긴 동일한 페이지를 공유하는 경우 단일 munlock() 또는 munlockall() 시스템 호출을 사용하여 잠금을 해제합니다. 따라서 이중 잠금 또는 단일 잠금 해제 문제를 방지하기 위해 애플리케이션이 잠금 해제하는 페이지를 알고 있어야 합니다.

다음은 이중 잠금 또는 단일 잠금 문제를 완화하는 가장 일반적인 두 가지 해결 방법입니다.

RHEL for Real Time 공유 라이브러리는 동적 공유 오브젝트(DSO)라고 하며 함수라는 미리 컴파일된 코드 블록 컬렉션입니다. 이러한 함수는 여러 프로그램에서 재사용할 수 있으며 런타임 시 로드되거나 컴파일됩니다.

Linux는 다음 두 가지 라이브러리 클래스를 지원합니다.

ld.so 동적 링커는 프로그램에 필요한 공유 라이브러리를 로드한 다음 코드를 실행합니다. DSO 함수는 메모리의 라이브러리를 한 번 로드하고 여러 프로세스가 프로세스의 주소 공간에 매핑하여 개체를 참조할 수 있습니다. LD_BIND_NOW 변수를 사용하여 컴파일 시 로드되도록 동적 라이브러리를 구성할 수 있습니다.

프로그램 초기화 전에 기호를 평가하면 애플리케이션 런타임에 평가하면 메모리 페이지가 외부 디스크에 있는 경우 대기 시간이 발생할 수 있으므로 성능이 향상될 수 있습니다.

RHEL for Real Time에서 공유 메모리는 여러 프로세스 간에 공유되는 메모리 공간입니다. 프로그램 스레드를 사용하면 한 프로세스 컨텍스트에서 생성된 모든 스레드가 동일한 주소 공간을 공유할 수 있습니다. 이렇게 하면 스레드가 모든 데이터 구조에 액세스할 수 있습니다. POSIX 공유 메모리 호출을 사용하면 주소 공간의 일부를 공유하도록 프로세스를 구성할 수 있습니다.

다음과 같은 지원되는 POSIX 공유 메모리 호출을 사용할 수 있습니다.

부동 소수점 단위는 부동 소수점 연산을 수행하는 프로세서의 기능 부분입니다.A floating point unit is the functional part of the processor that performs floating point arithmetic operations. 부동 소수점 단위는 수학적 작업을 처리하고 부동 숫자 또는 10진수 계산을 더 간단하게 만듭니다.

--matrix-method 옵션을 사용하면 CPU 부동 소수점 작업 및 프로세서 데이터 캐시 테스트를 과부하시킬 수 있습니다.

stress-ng 툴은 여러 번의 과부하 테스트를 실행합니다. 기본 모드에서는 지정된 과부하 메커니즘을 병렬로 실행합니다.

CPU heat 생성을 측정하기 위해 지정된 과부하는 최대 heat 생성에서 시스템의 난관 신뢰성 및 안정성을 테스트하기 위해 짧은 기간 동안 높은 온도를 생성합니다. --matrix-size 옵션을 사용하면 짧은 기간 동안 Celsius 수준의 CPU 온도를 측정할 수 있습니다.

stress-ng 툴은 초당 bogo 작업을 측정하여 과부하 테스트 처리량을 측정할 수 있습니다. bogo 작업 크기는 실행 중인 과부하에 따라 달라집니다. 테스트 결과는 정확하지 않지만 대략적인 성능 추정치를 제공합니다.

이 측정을 정확한 벤치마크 메트릭으로 사용해서는 안 됩니다. 이러한 추정치는 과부하를 구축하는 데 사용되는 다양한 커널 버전 또는 다양한 컴파일러 버전에서 시스템 성능 변경을 이해하는 데 도움이 됩니다. --metrics-brief 옵션을 사용하여 시스템에서 사용 가능한 총 bogo 작업 및 매트릭스 과부하 성능을 표시합니다.

메모리 부족 상태에 있으면 커널이 스왑에 페이지 쓰기를 시작합니다. --page-in 옵션을 사용하여 non-resident 페이지가 가상 메모리로 다시 스왑되도록 하여 가상 메모리를 과부하시킬 수 있습니다. 이로 인해 가상 머신이 크게 수행됩니다. --page-in 옵션을 사용하면 bigheap,mmap 및vm(가상 시스템) 과부하에 이 모드를 활성화할 수 있습니다. --page-in 옵션은 코어가 아닌 할당된 페이지를 터치하여 페이지로 강제 적용합니다.

고주파에서 타이머를 실행하면 큰 인터럽트 로드를 생성할 수 있습니다. 적절하게 선택된 타이머 빈도를 가진 --timer 다운 로더는 초당 많은 인터럽트를 강제할 수 있습니다.

stress-ng 를 사용하면 메모리에 로드되지 않은 페이지에 주요 페이지 폴트를 생성하여 페이지 폴트 속도를 테스트하고 분석할 수 있습니다. 새 커널 버전에서 userfaultfd 메커니즘은 프로세스의 가상 메모리 레이아웃에서 페이지 폴트에 대한 스레드를 찾는 오류를 알립니다.

CPU 스포크 테스트에는 CPU를 실행하는 방법이 포함되어 있습니다. 어떤 옵션을 사용하여 모든 메서드를 볼 수 있도록 출력을 출력할 수 있습니다.

기본적으로 테스트 방법을 지정하지 않으면 강조자가 라운드 로빈 방식으로 모든 강조자를 확인하여 각 스포터를 테스트합니다.

테스트가 활성화되면 확인 모드는 결과를 검증합니다. 이는 테스트 실행에서 메모리 콘텐츠를 확인하고 예기치 않은 오류를 보고합니다.

모든 과부하에는 확인 모드가 없으며 이를 활성화하면 이 모드에서 추가 검증 단계가 실행되기 때문에 bogo 작업 통계가 줄어듭니다.

실시간으로 레벨 사인 인터럽트는 마운드 전환을 제공하는 전용 인터럽트 라인을 사용합니다. 장치 컨트롤러는 인터럽트 요청 라인에서 신호를 어설션하여 인터럽트를 발생시킵니다. 인터럽트 라인은 두 개의 출력 중 하나를 전송하여 바이너리 1 또는 바이너리 0을 나타냅니다.

행에 의해 인터럽트 신호가 전송되면 CPU가 재설정될 때까지 해당 상태로 유지됩니다. CPU는 상태 저장을 수행하고 인터럽트를 캡처하고 인터럽트 처리기를 디스패치합니다. 인터럽트 처리기는 인터럽트의 원인을 결정하고 필요한 서비스를 수행하여 인터럽트를 지우고 장치의 상태를 복원합니다. 레벨 서명 인터럽트는 더 안정적이고 여러 장치를 지원하지만 구현하기가 어렵습니다.

실시간에서 많은 시스템은 MSI(Message-signaled interrupts)를 사용하여 패킷 또는 메시지 기반 기전 버스에서 신호를 전용 메시지로 전송합니다. 이러한 유형의 버스의 일반적인 예는 PCI Express 또는 PCIe(Peripheral Component Interconnect Express)입니다. 이러한 장치는 PCIe 호스트 컨트롤러가 인터럽트 메시지로 해석되는 메시지 유형을 전송합니다. 그러면 호스트 컨트롤러가 의 메시지를 CPU로 보냅니다.

실시간으로, 하드웨어에 따라 PCIe 시스템은 다음 중 하나를 수행합니다.

실시간으로 PCIe 시스템은 레거시 모드에서도 작동할 수 있습니다. 여기서 레거시 인터럽트 라인은 커널 명령줄에서 pci=nomsi 옵션을 사용하여 이전 운영 체제를 지원하거나 부팅 Linux 커널에서 구현됩니다.

실시간으로 마스킹할 수 없는 인터럽트는 시스템의 표준 인터럽트 마스킹 기술을 무시할 수 없는 하드웨어 인터럽트입니다. NMI는 마스크 가능한 인터럽트보다 우선 순위가 높습니다. NMI는 복구할 수 없는 하드웨어 오류에 대한 주의를 알리기 위해 발생합니다.

실시간 NMI는 일부 시스템에서 하드웨어 모니터로도 사용됩니다. 프로세서는 NMI를 수신할 때 인터럽트 벡터가 가리키는 NMI 처리기를 호출하여 NMI를 즉시 처리합니다. 지정된 시간 후에 트리거되지 않는 인터럽트와 같이 특정 조건이 충족되면 NMI 처리기에서 경고를 표시하고 문제에 대한 디버깅 정보를 제공합니다. 이를 통해 시스템 잠금을 식별하고 방지하는 데 도움이 됩니다.

실시간으로 마스크 가능한 인터럽트는 인터럽트 마스크 레지스터의 비트 마스크에 비트를 설정하여 무시할 수 있는 하드웨어 인터럽트입니다. CPU는 중요한 처리 중에 마스크 가능한 인터럽트를 일시적으로 무시할 수 있습니다.

실시간으로 시스템 관리 인터럽트(SMI)는 레거시 하드웨어 장치 에뮬레이션과 같은 확장된 기능을 제공하며 시스템 관리 작업에도 사용할 수 있습니다. SMIS는 마스크 불가능한 인터럽트 (NMI)와 유사하며 일반적으로 마스크를 사용할 수 없습니다. SMI가 발생하면 CPU가 시스템 관리 모드(SMM)로 들어갑니다. 이 모드에서 특수 하위 수준 처리기는 SMI를 처리하기 위해 실행됩니다. SMM은 일반적으로 시스템 관리 펌웨어, 종종 BIOS 또는 EFI에서 직접 제공됩니다.

실시간 SMI는 레거시 하드웨어 에뮬레이션을 제공하는 데 가장 자주 사용됩니다. 일반적인 예는 디스크lets 드라이브를 모방하는 것입니다. 디스크lets 드라이브가 연결되어 있지 않으면 운영 체제는 디스크 스탠자에 액세스하려고 시도하며 SMI를 트리거합니다. 이 시나리오에서 처리기는 운영 체제에 에뮬레이션된 장치를 대신 제공합니다. 그런 다음 운영 체제는 에뮬레이션을 레거시 장치로 처리합니다.

SMI는 실시간으로 운영 체제의 직접적인 개입 없이 시스템에 부정적인 영향을 미칠 수 있습니다. 잘못 작성된 SMI 처리 루틴은 수 밀리초의 CPU 시간을 사용할 수 있으며 운영 체제는 처리기를 선점하지 못할 수 있습니다. 이로 인해 다른 잘 조정되고 반응성이 높은 시스템에서 주기적인 높은 대기 시간을 생성할 수 있습니다. 벤더는 CPU 온도 및 팬 제어를 관리하기 위해 SMI 처리기를 사용할 수 있으므로 비활성화할 수 없습니다. 이러한 상황에서는 이러한 인터럽트를 사용할 때 발생하는 문제에 대해 공급업체에게 알려야 합니다.

실시간으로 hwlatdetect 유틸리티를 사용하여 SMI를 분리할 수 있습니다. rt-tests 패키지에서 사용할 수 있습니다. 이 유틸리티는 SMI 처리 루틴에서 CPU를 사용하는 기간을 측정합니다.

Intel Corporation에서 개발한 고급 프로그래밍 가능 인터럽트 컨트롤러(APIC)는 다음을 수행할 수 있는 기능을 제공합니다.

실시간 APIC는 확장 가능하고 관리 가능한 방식으로 다수의 하드웨어 인터럽트를 생성, 라우팅 및 처리하기 위해 함께 작동하는 일련의 장치 및 기술을 나타냅니다. 각 시스템 CPU에 내장된 로컬 APIC와 하드웨어 장치에 직접 연결된 여러 입력/출력 APIC를 사용합니다.

실시간으로 하드웨어 장치가 인터럽트를 생성할 때 연결된 I/O APIC는 시스템 APIC 버스 전체의 인터럽트를 특정 CPU로 탐지하고 라우팅합니다. 운영 체제는 IO-APIC가 장치에 연결되고 해당 장치 내의 인터럽트 라인을 알고 있습니다. Advanced Configuration and Power Interface Differentiated System Description Table (ACPI DSDT)에는 호스트 시스템 마더보드 및 주변 구성 요소의 특정 설정에 대한 정보가 포함되어 있으며 장치는 사용 가능한 인터럽트 소스에 대한 정보를 제공합니다. 이러한 두 가지 데이터 세트는 전체 인터럽트 계층 구조에 대한 정보를 제공합니다.

RHEL for Real Time은 계층 구조로 연결된 시스템 APIC 기반 인터럽트 관리 전략을 지원하고 특정 CPU 또는 CPU 세트를 대상으로 하는 대신 부하 분산 방식으로 CPU에 인터럽트를 전달합니다.

가장 간단한 관점에서 실시간 프로세스는 실행 중인 프로그램입니다. 용어 프로세스는 여러 스레드가 잠재적으로 포함된 독립적인 주소 공간을 나타냅니다. 한 주소 공간 내에서 실행되는 두 개 이상의 프로세스의 개념이 개발되면 Linux는 다른 프로세스와 주소 공간을 공유하는 프로세스 구조로 전환되었습니다. 이는 프로세스 데이터 구조가 작을 때 제대로 작동합니다.

UNIX® 스타일 프로세스 구성에는 다음이 포함됩니다.

실시간으로 각 프로세스는 종종 부모 스레드라고 하는 단일 스레드로 시작합니다. fork() 시스템 호출을 사용하여 상위 스레드에서 추가 스레드를 생성할 수 있습니다. fork() 는 새 프로세스 ID를 제외하고 상위 프로세스와 동일한 새 하위 프로세스를 생성합니다. 하위 프로세스는 생성 프로세스와 독립적으로 실행됩니다. 상위 및 하위 프로세스를 동시에 실행할 수 있습니다. fork() 와 exec() 시스템 호출의 차이점은 fork() 가 상위 프로세스의 복사본인 새 프로세스를 시작하고 exec() 는 현재 프로세스 이미지를 새 프로세스 이미지로 대체한다는 것입니다.

실시간으로 fork() 시스템 호출이 성공하면 하위 프로세스의 프로세스 식별자가 반환되고 상위 프로세스는 0이 아닌 값을 반환합니다. 오류 발생 시 오류 번호를 반환합니다.

실시간으로 여러 스레드가 프로세스 내에 존재할 수 있습니다. 프로세스의 모든 스레드는 가상 주소 공간과 시스템 리소스를 공유합니다. 스레드는 다음을 포함하는 스케줄링 가능한 엔티티입니다.

실시간에서는 병렬 처리를 생성하기 위한 잠재적인 메커니즘이 있습니다.

실시간 스레드를 생성하기 전에 구성 요소 상호 작용 수준을 평가해야 합니다. 새 주소 공간을 만들고 새 프로세스로 실행하면 구성 요소가 서로 독립적이거나 상호 작용이 적을 때 유용합니다. 데이터를 공유하거나 자주 통신하는 데 구성 요소가 필요한 경우 하나의 주소 공간 내에서 스레드를 실행하는 것이 더 효율적입니다.

실시간으로 fork() 시스템 호출이 성공하면 0 값을 반환합니다. 오류 발생 시 오류 번호를 반환합니다.

NUMA(Non-Uniform Memory Access) 및 SMP(Symmetric Multiprocessing)와 같은 다중 프로세서 시스템에서 발견된 클럭 소스의 여러 인스턴스는 CPU 빈도 스케일링 또는 에너지 경제 모드 입력과 같은 시스템 이벤트에 반응하는 방식을 상호 작용하며 실시간 커널에 적합한 클럭 소스인지 결정합니다.

기본 클록 소스는 TSC(Time Stamp Cryostat)입니다. TSC를 사용할 수 없는 경우 HPET(High Precision Event Timer)이 두 번째 최상의 옵션입니다. 그러나 모든 시스템에 HPET 시계가 있는 것은 아니며 일부 HPET 클록은 신뢰할 수 없습니다.

TSC 및 HPET가 없는 다른 옵션에는 ACPI_PM (ACPI_PM), Programmable Interval Timer (PIT) 및 Real Time Clock (RTC)이 포함됩니다. 마지막 두 옵션은 읽기에는 비용이 많이 들거나 낮은 해상도(시간 단위)가 있으므로 실시간 커널과 함께 사용할 수 있습니다.

POSIX는 시간 소스를 구현하고 나타내는 표준입니다. 시스템의 다른 애플리케이션에 영향을 주지 않고 애플리케이션에 POSIX 시계를 할당할 수 있습니다. 이는 커널에서 선택하고 시스템 전체에서 구현되는 하드웨어 클록과 대조적입니다.

지정된 POSIX 시계를 읽는 데 사용되는 함수는 <time .h>에 정의된 clock_gettime() 입니다. clock_gettime() 과 반대되는 커널은 시스템 호출입니다. 사용자 프로세스가 clock_gettime() 을 호출할 때:

그러나 사용자 애플리케이션에서 커널로의 컨텍스트 전환에는 CPU 비용이 있습니다. 이러한 비용은 매우 낮지만 작업이 수천 번 반복되면 누적된 비용이 애플리케이션의 전체 성능에 영향을 미칠 수 있습니다. 커널로 컨텍스트 전환을 방지하기 위해 더 빠르게 클럭을 읽을 수 있도록 CLOCK_MONOTONIC_COARSE 및 CLOCK_REALTIME_COARSE POSIX 클록에 대한 지원이 VDSO(가상 동적 공유 오브젝트) 라이브러리 함수 형태로 추가되었습니다.

_COARSE 클럭 변형 중 하나를 사용하여 clock_gettime() 에 의해 수행되는 시간 읽기는 커널 개입이 필요하지 않으며 사용자 공간에서 완전히 실행됩니다. 이는 상당한 성능 이점을 제공합니다. _COARSE 클록에 대한 시간 읽기에는 밀리 초(ms) 해상도가 있으므로 1ms보다 작은 시간 간격은 기록되지 않습니다. POSIX 클록의 _COARSE 변형은 밀리 초 클록 해상도를 수용할 수 있는 모든 애플리케이션에 적합합니다.

다음 코드는 CLOCK_MONOTONIC_COARSE POSIX 클록과 함께 clock_gettime() 함수를 사용하는 코드 예제를 보여줍니다.

#include <time.h>
main()
{
	int rc;
	long i;
	struct timespec ts;

	for(i=0; i<10000000; i++) {
		rc = clock_gettime(CLOCK_MONOTONIC_COARSE, &ts);
	}
}

위 예제에서는 clock_gettime() 의 반환 코드를 확인하기 위해 검사를 추가하거나, rc 변수의 값을 확인하거나, ts 구조의 내용을 신뢰할 수 있도록 하여 개선할 수 있습니다.

실시간 스레드는 표준 스레드보다 우선 순위가 높습니다. 정책에는 최소 값 1에서 최대 99까지의 스케줄링 우선순위 값이 있습니다.

다음 정책은 실시간에 중요합니다.

각 Cryostat_DEADLINE 작업은 마침표,런타임 및 데드라인 매개 변수로 지정됩니다. 이러한 매개변수의 값은 나노초의 정수입니다.

Red Hat Enterprise Linux의 sched_deadline_period_max_us 및 sched_deadline_period_min_us 매개변수는 Cryostat_DEADLINE 스케줄링 정책의 커널 조정 가능한 매개변수입니다. 이러한 매개변수는 이 실시간 스케줄링 클래스를 사용하여 작업에 대해 허용되는 최대 및 최소 기간(마이크로초)을 제어합니다.

sched_deadline_period_max_us 및 sched_deadline_period_min_us 는 함께 작동하여 period 값에 대한 허용 가능한 범위를 정의합니다.

매개 변수의 값은 마이크로초 단위입니다. 예를 들어 1초는 100000 마이크로초와 동일합니다.

RV(런타임 확인) 모니터는 RV 모니터 내에 캡슐화되고 정의된 사양과 커널 추적 간에 조정되어 추적 파일에서 런타임 이벤트를 캡처합니다. RV 모니터에는 다음이 포함됩니다.

런타임 시 시스템을 확인하고 모니터링하는 것 외에도 예기치 않은 시스템 이벤트에 대한 응답을 활성화할 수 있습니다. 반응 방식은 안전 크리티컬 시스템에서 시스템 실패를 방지하기 위해 종료와 같은 극단적인 반응을 시작하기 위해 추적 파일에서 이벤트를 캡처하는 것과는 다를 수 있습니다.

반응기는 필요에 따라 시스템 이벤트에 대한 응답을 정의하기 위해 RV 모니터에 사용할 수 있는 반응 방법입니다. 기본적으로 모니터는 작업의 추적 출력을 제공합니다.

RV(런타임 확인) 모니터는 다음과 같은 유형으로 분류됩니다.

사용자 인터페이스는 /sys/kernel/tracing/rv 에 있으며 추적 인터페이스와 유사합니다. 사용자 인터페이스에는 언급된 파일 및 폴더가 포함됩니다.

기본적으로 프로세스는 모든 CPU에서 실행할 수 있습니다. 그러나 프로세스의 선호도를 변경하여 사전 정의된 CPU에서 실행되도록 프로세스를 구성할 수 있습니다. 하위 프로세스는 상위 프로세스의 CPU 특성을 상속합니다.

시스템에서 기능 조정에 대한 실시간 관행은 애플리케이션을 실행하는 데 필요한 코어 수를 확인한 다음 해당 코어를 격리하는 것입니다. 이는 Tuna 툴을 사용하거나 쉘 스크립트를 사용하여 비트마스크 값을 수정할 수 있습니다.

taskset 명령은 프로세스의 선호도를 변경하고 /proc/ filesystem 항목을 수정하면 인터럽트의 선호도를 변경할 수 있습니다. p 또는 --pid 옵션과 함께 taskset 명령을 사용하고 프로세스의 PID(프로세스 ID)를 사용하여 프로세스의 선호도를 확인합니다.

-c 또는 --cpu-list 옵션은 비트마스크 대신 코어 수 목록을 표시합니다. 특정 프로세스를 바인딩할 CPU 수를 지정하여 선호도를 설정할 수 있습니다. 예를 들어 CPU 0 또는 CPU 1을 이전에 사용한 프로세스의 경우 CPU 1에서만 실행할 수 있도록 선호도를 변경할 수 있습니다. taskset 명령 외에도 sched_setaffinity() 시스템 호출을 사용하여 프로세서 선호도를 설정할 수도 있습니다.

커널의 데드라인 스케줄링 클래스( Cryostat_DEADLINE)는 제한된 기한이 지정된 작업에 대해 초기 데드라인(EDF)을 구현합니다. 작업 데드라인에 따라 작업의 우선 순위를 지정합니다. 가장 빠른 절대 데드라인이 먼저 수행됩니다. EDF 스케줄러 외에도 데드라인 스케줄러는 일정 대역폭 서버(CBS)도 구현합니다. CBS 알고리즘은 리소스 예약 프로토콜입니다.

CBS는 각 작업이 모든 기간 (T) 에서 실행 시간 (Q) 을 수신하는 것을 보장합니다. 작업의 모든 활성화가 시작될 때 CBS는 작업의 실행 시간을 보완합니다. 작업이 실행되면 해당 런타임 을 사용하고 작업이 런타임 이 부족하면 작업이 제한되고 예약 해제됩니다. 제한 메커니즘은 단일 작업이 런타임 이상의 실행을 방지하고 다른 작업의 성능 문제를 방지하는 데 도움이 됩니다.

실시간으로 데드라인 작업으로 시스템 과부하를 방지하기 위해 데드라인 스케줄러는 데드라인 스케줄러로 실행되도록 작업이 구성될 때마다 실행되는 승인 테스트를 구현합니다. 수락 테스트에서는 Cryostat _DEADLINE 작업이 kernel.sched_rt_runtime_us/kernel.sched_rt_period_us 파일에 지정된 CPU 시간보다 더 많은 CPU 시간을 사용하지 않도록 합니다. 기본적으로 1s를 통한 950ms입니다.

Mutex는 상호 제외라는 용어에서 파생됩니다. 상호 제외 오브젝트는 리소스에 대한 액세스를 동기화합니다. 한 번에 하나의 스레드만 뮤텍스를 얻을 수 있도록 하는 메커니즘입니다.

코드의 각 섹션에 대한 직렬 액세스를 만들어 하나의 스레드만 한 번에 코드를 실행하도록 합니다. Mutexes는 뮤지션 특성 개체라고 하는 특성 개체를 사용하여 생성됩니다.Mutexes are created by using an attribute object known as the mutex attribute object. 이는 구현하도록 선택한 POSIX 옵션에 따라 다양한 속성을 포함하는 추상 오브젝트입니다. 특성 오브젝트는 pthread_mutex_t 변수로 정의됩니다. 개체는 뮤지션에 대해 정의된 특성을 저장합니다. pthread_mutex_init(&my_mutex, &my_mutex_attr), pthread_mutexattr_setbust() 및 pthread_mutexattr_getrobust() 함수는 0을 반환합니다. 오류가 발생하면 오류 번호를 반환합니다.

실시간으로 특성 개체를 유지하여 동일한 형식의 더 많은 뮤지션을 초기화하거나 특성 개체를 정리(destroy)할 수 있습니다.In real-time, you can either retain the attribute object to initialize more mutexes of the same type or you can clean up (destroy) the attribute object. 뮤지컬은 두 경우 모두 영향을 받지 않습니다. 뮤텍스에는 표준 및 고급 유형의 뮤지셔너스가 포함됩니다.

Robust 뮤지션이 자동으로 해제되지 않고 수동으로 해제할 때까지 잠길 수 있습니다.

경계는 다른 스레드 동기화 방법과 비교할 때 매우 다른 방식으로 작동합니다. 경계선은 모든 스레드와 프로세스가 이 장벽에 도달할 때까지 모든 활성 스레드가 중지되는 코드의 지점을 정의합니다. 경계는 실행 중인 애플리케이션이 실행을 계속하기 전에 모든 스레드가 특정 작업을 완료하도록 해야 하는 경우에 사용됩니다.

장벽 뮤지션은 다음 두 가지 변수를 사용합니다.

장벽은 지정된 수의 스레드가 정의된 장벽에 도달할 때만 전달되도록 상태를 설정합니다. 장벽 상태가 전달되도록 설정되면 스레드와 프로세스가 더 계속 진행됩니다. pthread_barrier_init() 함수는 필요한 리소스를 할당하여 정의된 장벽을 사용하고 attr 속성 개체에서 참조하는 속성으로 초기화합니다.

pthread_barrier_init() 및 pthread_barrier_destroy() 함수는 성공하면 0 값을 반환합니다. 오류가 발생하면 오류 번호가 반환됩니다.

실시간으로 조건 변수(condvar)는 진행하기 전에 특정 조건이 달성될 때까지 기다리는 POSIX 스레드 구조입니다. 일반적으로 신호된 조건은 스레드가 다른 스레드와 공유하는 데이터 상태와 관련이 있습니다. 예를 들어 condvar 를 사용하여 데이터 항목을 처리 큐로 신호하고 큐에서 해당 데이터를 처리하기 위해 대기 중인 스레드를 사용할 수 있습니다. pthread_cond_init() 함수를 사용하면 조건 변수를 초기화할 수 있습니다.

pthread_cond_init(), pthread_cond_wait() 및 pthread_cond_signal() 함수는 성공하면 0 값을 반환합니다. 오류가 발생하면 오류 번호를 반환합니다.

언급된 Mutex 옵션은 애플리케이션을 작성하거나 이식할 때 고려할 뮤지션 클래스에 대한 지침을 제공합니다.

언급된 함수 유형 목록과 설명은 실시간 커널의 스레드 동기화 메커니즘에 사용할 기능에 대한 정보를 제공합니다.

TCP_NODELAY 소켓 옵션은 나글의 알고리즘을 비활성화합니다. setsockopt sockets API 함수를 사용하여 TCP_NODELAY 를 구성하면 즉시 개별 패킷으로 여러 개의 작은 버퍼 쓰기가 전송됩니다.

보내기 전에 연속 패킷을 빌드하여 여러 논리 관련 버퍼를 단일 패킷으로 전송하면 대기 시간과 성능이 향상됩니다. 또는 메모리 버퍼가 논리적으로 관련이 있지만 연속적이지 않은 경우 I/O 벡터를 만들고 TCP_NODELAY 가 활성화된 소켓에서 writev 를 사용하여 커널에 전달할 수 있습니다.

다음 예제에서는 setsockopt 소켓 API를 통해 TCP_NODELAY 를 활성화하는 방법을 보여줍니다.

int one = 1;
setsockopt(descriptor, SOL_TCP, TCP_NODELAY, &one, sizeof(one));

TCP_CORK 옵션은 소켓의 모든 데이터 패킷을 수집하고 버퍼가 지정된 제한으로 채워질 때까지 전송하지 않습니다. 이를 통해 애플리케이션은 커널 공간에 패킷을 빌드하고 TCP_CORK 가 비활성화되면 데이터를 보낼 수 있습니다. TCP_CORK 는 setsocketopt() 함수를 사용하여 소켓 파일 설명자에 설정됩니다. 프로그램을 개발할 때 파일에서 대량 데이터를 보내야하는 경우 sendfile() 함수와 함께 TCP_CORK 를 사용하는 것이 좋습니다.

논리 패킷이 다양한 구성 요소에서 커널에 빌드되면 setsockopt 소켓 API를 사용하여 1 값으로 구성하여 TCP_CORK 를 활성화합니다. 이를 "corking the socket"이라고 합니다. TCP_CORK 는 코크가 적절한 시간에 제거되지 않는 경우 버그가 발생할 수 있습니다.

다음 예제에서는 setsockopt 소켓 API를 통해 TCP_CORK 를 활성화하는 방법을 보여줍니다.

int one = 1;
setsockopt(descriptor, SOL_TCP, TCP_CORK, &one, sizeof(one));

일부 환경에서는 커널이 코크를 제거할 시기를 확인할 수 없는 경우 다음과 같이 수동으로 제거할 수 있습니다.

int zero = 0;
setsockopt(descriptor, SOL_TCP, TCP_CORK, &zero, sizeof(zero));

TCP_NODELAY 및 TCP_CORK 소켓 옵션은 네트워크 연결 동작에 큰 영향을 미칩니다. TCP_NODELAY 는 데이터 패킷을 준비한 즉시 전송할 수 있는 애플리케이션에 대해 나글의 알고리즘을 비활성화합니다. TCP_CORK 를 사용하면 서로 지연 없이 여러 데이터 패킷을 동시에 전송할 수 있습니다.

gcc tcp_nodelay_client.c -o tcp_nodelay_client -lrt

예제 프로그램은 이러한 소켓 옵션이 애플리케이션에 미칠 수 있는 성능에 대한 정보를 제공합니다.

다음 예제에서는 루프백 인터페이스를 사용하여 다음 세 가지 변형을 보여줍니다.

chrt 유틸리티는 스케줄러 정책 및 우선 순위를 확인하고 조정합니다. 원하는 속성으로 새 프로세스를 시작하거나 실행 중인 프로세스의 현재 속성을 변경할 수 있습니다.

chrt 유틸리티는 --pid 또는 -p 옵션을 사용하여 프로세스 ID(PID)를 지정합니다.

chrt 유틸리티는 다음과 같은 정책 옵션을 사용합니다.

다음 예제에서는 지정된 프로세스의 특성을 보여줍니다.

# chrt -p 468
pid 468’s current scheduling policy: SCHED_FIFO
pid 468’s current scheduling priority: 85

실시간 선점은 나중에 다시 시작할 의도로 실행 중인 작업을 일시적으로 중단하는 메커니즘입니다. 우선 순위가 높은 프로세스가 CPU 사용량을 중단하면 발생합니다. 선점은 성능에 특히 부정적인 영향을 미칠 수 있으며 지속적인 선점은 충돌이라는 상태로 이어질 수 있습니다. 이 문제는 프로세스가 지속적으로 선점되고 프로세스가 완전히 실행되지 않을 때 발생합니다. 작업의 우선 순위를 변경하면 비자발적 선점을 줄이는 데 도움이 될 수 있습니다.

/proc/PID/status 파일의 내용을 확인하여 단일 프로세스에서 발생하는 번거롭고 불필요한 선점을 확인할 수 있습니다. 여기서 PID는 프로세스 식별자입니다.

다음 예제에서는 PID 1000이 있는 프로세스의 선점 상태를 보여줍니다.

# grep voluntary /proc/1000/status
voluntary_ctxt_switches: 194529
nonvoluntary_ctxt_switches: 195338

실시간 프로세스는 다른 라이브러리 호출 세트를 사용하여 정책 및 우선 순위를 제어합니다. 함수에는 sched.h 헤더 파일이 포함되어야 합니다. 기호 는 sched.h 헤더 파일에 정의되어 있어야 합니다.

표에는 실시간 스케줄러의 정책 및 우선 순위를 설정하는 함수가 나열되어 있습니다.

sched_yield() 함수는 프로세서가 실행 중인 프로세스 이외의 프로세스를 선택하도록 설계되었습니다. 이러한 유형의 요청은 잘못 작성된 애플리케이션 내에서 발행된 경우 실패하기 쉽습니다.

sched_yield() 함수가 실시간 우선순위가 있는 프로세스 내에서 사용하면 예기치 않은 동작을 표시할 수 있습니다. sched_yield() 를 호출하는 프로세스는 동일한 우선 순위로 실행되는 프로세스의 테일로 이동합니다. 동일한 우선 순위에서 다른 프로세스가 실행되지 않으면 sched_yield() 라는 프로세스가 계속 실행됩니다. 해당 프로세스의 우선 순위가 높으면 잠재적으로 사용 중인 루프를 생성하여 머신을 사용할 수 없게 될 수 있습니다.

일반적으로 실시간 프로세스에서 sched_yield() 를 사용하지 마십시오.

getrusage() 함수는 지정된 프로세스 또는 해당 스레드에서 중요한 정보를 검색합니다. 다음과 같은 정보를 보고합니다.

getrusage() 를 사용하면 성능 튜닝 및 디버깅 활동과 관련된 정보를 제공하도록 애플리케이션을 쿼리할 수 있습니다. getrusage() 는 /proc/ 디렉터리에 있는 여러 다른 파일에서 카탈로그해야 하는 정보를 검색하고 애플리케이션의 특정 작업 또는 이벤트와 동기화하기가 어렵습니다.

추적 시스템의 curret_tracer 파일에 timerlat 을 추가하여 타이머 추적기를 구성할 수 있습니다. current_tracer 파일은 일반적으로 /sys/kernel/tracing 디렉터리에 마운트됩니다. 타이머 내역 추적기는 인터럽트 요청(IRQ)을 측정하고 스레드 대기 시간이 100 마이크로초를 초과하면 분석을 위해 추적 출력을 저장합니다.

timerlat 추적기는 osnoise tracer 위에 빌드됩니다. 따라서 /osnoise/config 디렉토리에서 옵션을 설정하여 스레드 스케줄링 대기 시간에 대한 정보를 추적하고 캡처할 수 있습니다.

rtla-timerlat-top 추적기에는 타이머 추적기 에서 주기적인 출력 요약이 표시됩니다. 추적기 출력은 또한 각 운영 체제의 노이즈 및 이벤트(예: osnoise ) 및 tracepoints 에 대한 정보를 제공합니다. 이 정보는 -t 옵션을 사용하여 볼 수 있습니다.

rtla timerlat top --help 명령을 사용하면 rtla-timerlat-top 추적기 에 대한 옵션에 대한 도움말 사용법을 볼 수 있습니다.

Linux 커널에는 운영 체제 노이즈(osnoise) 추적기에 대한 인터페이스를 제공하는 실시간 분석(rtla) 툴이 포함되어 있습니다. rtla-osnoise 추적기에서는 지정된 기간에 대해 주기적으로 실행되는 스레드를 생성합니다. 기간이 시작될 때 스레드는 인터럽트를 비활성화하고 샘플링을 시작하고 루프에서 시간을 캡처합니다.

rtla-osnoise 추적기에서는 다음과 같은 기능을 제공합니다.

rtla-osnoise 추적기에서는 기간 종료 시 노이즈 소스에 대한 다음 정보가 포함된 실행 보고서를 출력합니다.

추적 시스템의 curret_tracer 파일에 osnoise 를 추가하여 rtla-osnoise 추적기를 구성할 수 있습니다. current_tracer 파일은 일반적으로 /sys/kernel/tracing/ 디렉터리에 마운트됩니다. rtla-osnoise 추적기에서는 인터럽트 요청(IRQ)을 측정하고 단일 노이즈 발생을 위해 스레드 대기 시간이 20 마이크로초 이상인 경우 분석을 위해 추적 출력을 저장합니다.

rtla-osnoise 추적기에 대한 구성 옵션은 /sys/kernel/tracing/ 디렉터리에서 사용할 수 있습니다.

rtla-osnoise 에는 운영 체제 노이즈의 소스를 식별하는 일련의 추적 포인트 가 포함되어 있습니다(osnoise).

osnoise/options 파일에는 rtla-osnoise 추적기 에 대한 설정 옵션 세트가 포함되어 있습니다.

rtla osnoise-top tracer는 유해 소스의 발생 카운터에 대한 정보와 함께 osnoise 추적기의 주기적인 요약을 측정하고 출력합니다.

rtla osnoise top --help 명령을 사용하면 rtla-osnoise-top 추적기에 사용 가능한 옵션에 대한 도움말 사용량을 볼 수 있습니다.

실시간 스케줄링 정책은 하나의 주요 특성을 공유합니다. 높은 우선 순위 스레드가 스레드 또는 스레드가 I/O를 잠급거나 수행하여 대기할 때까지 실행됩니다.

Cryostat _RR 의 경우 운영 체제는 실행 중인 스레드를 중단하여 동일한 Cryostat _RR 우선순위의 다른 스레드를 실행할 수 있도록 합니다. 이러한 경우 중 하나에서 더 낮은 우선 순위 스레드가 CPU 시간을 얻을 수 있도록 정책을 정의하는 POSIX 사양에 의해 프로비저닝이 이루어지지 않습니다. 실시간 스레드의 이러한 특성은 지정된 CPU의 100%를 단조하는 애플리케이션을 쉽게 작성할 수 있음을 의미합니다. 그러나 이로 인해 운영 체제에 문제가 발생합니다. 예를 들어, 운영 체제는 시스템 전체 및 CPU당 리소스를 모두 관리해야 하며 이러한 리소스를 설명하는 데이터 구조를 주기적으로 검사하고 하우스키핑 활동을 수행해야 합니다. 그러나 코어가 Cryostat _FIFO 스레드에 의해 단조되는 경우 하우스키핑 작업을 수행할 수 없습니다. 결국 전체 시스템이 불안정해지고 잠재적으로 충돌할 수 있습니다.

RHEL for Real Time 커널에서 인터럽트 처리기는 Cryostat _FIFO 우선 순위로 스레드로 실행됩니다. 기본 우선순위는 50입니다. 인터럽트 처리기 스레드보다 높은 Cryostat _FIFO 또는 Cryostat _RR 정책이 있는 cpu-hog 스레드는 인터럽트 처리기가 실행되지 않도록 할 수 있습니다. 이로 인해 프로그램이 인터럽트에 의해 전달되는 데이터 신호를 대기하고 실패하게 됩니다.

실시간 커널에는 실시간 작업에서 사용할 대역폭을 할당할 수 있는 보호 메커니즘이 포함되어 있습니다. 보호 메커니즘을 실시간 스케줄러 제한이라고 합니다.

실시간 제한 메커니즘의 기본값은 실시간 작업에서 CPU 시간의 95%를 사용할 수 있음을 정의합니다. 나머지 5%는 Cryostat _OTHER 및 유사한 스케줄링 정책에서 실행되는 작업과 같이 실시간이 아닌 작업에 사용됩니다. 단일 실시간 작업이 95% CPU 시간 슬롯을 사용하는 경우 해당 CPU의 나머지 실시간 작업이 실행되지 않습니다. 실시간이 아닌 작업만 나머지 5%의 CPU 시간을 사용합니다. 기본값은 다음과 같은 성능에 영향을 미칠 수 있습니다.

실시간 스케줄러 제한은 /proc 파일 시스템의 다음 매개변수에 의해 제어됩니다.

스레드 중단은 스레드가 별표 임계값보다 오래 CPU 실행 대기열에 있고 진행되지 않을 때 발생합니다. 스레드 중단의 일반적인 원인은 CPU에 바인딩된 Cryostat _FIFO 또는 Cryostat _ RR 과 같은 고정 우선 순위의 폴링 애플리케이션을 실행하는 것입니다. 폴링 애플리케이션은 I/O를 차단하지 않으므로 kworkers 와 같은 다른 스레드가 해당 CPU에서 실행되지 않도록 할 수 있습니다.

스레드 중단을 줄이기 위한 초기 시도는 실시간 제한이라고 합니다. 실시간 제한에서 각 CPU에는 실시간이 아닌 작업 전용 실행 시간의 일부가 있습니다. 제한의 기본 설정은 실시간 작업에 대해 CPU의 95%를 사용하고 5%는 비실시간 작업을 위해 예약되어 있습니다. 이 작업은 단일 실시간 작업으로 인해 중단을 유발하지만 CPU에 할당된 실시간 작업이 여러 개 있는 경우 작동하지 않습니다. 다음을 사용하여 문제를 해결할 수 있습니다.