Linux CPU에서 컨텍스트 전환 탐색

우리 모두 알고 있듯이 Linux는 동시에 실행할 수 있는 작업 수가 CPU 수를 훨씬 초과하는 멀티태스킹을 지원하는 운영 체제입니다. 물론 이러한 작업이 실제로 동시에 실행되는 것은 아니지만(단일 CPU의 경우) 시스템이 짧은 시간 동안 이러한 작업에 차례로 CPU를 할당하기 때문에 동시에 여러 작업이 실행되는 것처럼 보이게 됩니다. .

CPU 컨텍스트

각 작업이 실행되기 전에 CPU는 해당 작업을 로드하고 시작할 위치를 알아야 합니다. 이는 시스템이 CPU의 레지스터 및 프로그램 카운터를 미리 설정해야 함을 의미합니다.

CPU 레지스터는 CPU에 내장된 작지만 매우 빠른 메모리입니다. 프로그램 카운터는 CPU에서 현재 실행 중인 명령어의 위치나 다음에 실행할 명령어의 위치를 ​​저장하는 데 사용됩니다.

이 두 가지 모두 CPU가 작업을 수행하기 전에 필요한 환경이므로 "CPU 컨텍스트"라고 합니다. 아래 사진을 참고하세요:

이제 CPU 컨텍스트가 무엇인지 알았으니 CPU 컨텍스트 전환을 이해하기 쉬울 것 같습니다. "CPU 컨텍스트 전환"은 이전 작업의 CPU 컨텍스트(CPU 레지스터 및 프로그램 카운터)를 저장한 다음 새 작업의 컨텍스트를 이러한 레지스터 및 프로그램 카운터에 로드하고 마지막으로 프로그램 카운터로 점프하는 것을 의미합니다.

이러한 저장된 컨텍스트는 시스템 커널에 저장되고 작업 실행 일정이 변경되면 다시 로드됩니다. 이렇게 하면 작업의 원래 상태가 영향을 받지 않고 작업이 계속 실행되는 것처럼 보입니다.

CPU 컨텍스트 전환 유형

CPU 컨텍스트 전환은 CPU 레지스터와 프로그램 카운터 값을 업데이트하는 것에 지나지 않으며 이러한 레지스터는 작업을 빠르게 실행하도록 설계되었는데 CPU 성능에 영향을 미치는 이유는 무엇입니까?

이 질문에 답하기 전에 이러한 "작업"이 무엇인지 생각해 본 적이 있나요? 작업은 프로세스 또는 스레드라고 말할 수 있습니다. 예, 프로세스와 스레드가 가장 일반적인 작업이지만 그 외에도 다른 유형의 작업이 있습니다.

잊지 마세요하드웨어 인터럽트도 일반적인 작업입니다. 하드웨어 트리거 신호로 인해 인터럽트 핸들러가 호출됩니다.

따라서 CPU 컨텍스트 스위치에는 최소한 세 가지 유형이 있습니다.

• 프로세스 컨텍스트 전환
• 스레드 컨텍스트 전환
• 인터럽트 컨텍스트 전환

하나씩 살펴보겠습니다.

프로세스 컨텍스트 전환

Linux는 권한 수준에 따라 프로세스의 실행 공간을 커널 공간과 사용자 공간으로 나누는데, 이는 아래 그림의 CPU 권한 수준 Ring 0 和 Ring 3에 해당합니다.

• 커널 공간(Ring 0)은 가장 높은 권한을 가지며 모든 리소스에 직접 액세스할 수 있습니다
• 사용자 공간(Ring 3)은 제한된 리소스에만 접근할 수 있으며 메모리 등의 하드웨어 장치에 직접 접근할 수 없습니다. 이러한 권한 있는 리소스에 액세스하려면 시스템 호출을 통해 커널에 트랩핑되어야 합니다.

다른 관점에서 보면 프로세스는 사용자 공간과 커널 공간 모두에서 실행될 수 있습니다. 프로세스가 사용자 공간에서 실행 중일 때 이를 프로세스의 사용자 상태라고 합니다. 커널 공간에 속하면 프로세스의 커널 상태라고 합니다.

사용자 모드에서 커널 모드로의 전환은 시스템 호출을 통해 완료되어야 합니다. 예를 들어, 파일의 내용을 볼 때 다음 시스템 호출이 필요합니다:

• open(): 파일 열기
• read(): 파일 내용 읽기
• write(): 파일 내용을 출력 파일에 씁니다(표준 출력 포함)
• close(): 파일 닫기

그렇다면 위의 시스템 호출 중에 CPU 컨텍스트 전환이 발생할까요? 물론.

이렇게 하려면 먼저 CPU 레지스터에 원래 사용자 모드 명령어의 위치를 ​​저장해야 합니다. 다음으로, 커널 모드 코드를 실행하려면 CPU 레지스터를 커널 모드 명령의 새 위치로 업데이트해야 합니다. 마지막으로 커널 상태로 점프하여 커널 작업을 실행합니다.

그런 다음 시스템 호출이 끝나면 CPU 레지스터는 원래 저장된 사용자 상태를 복원한 다음 사용자 공간으로 전환하여 프로세스를 계속 실행해야 합니다.

따라서 시스템 호출 중에는 실제로 두 개의 CPU 컨텍스트 전환이 있습니다.

그러나 시스템 호출 프로세스에는 프로세스 전환이 포함되지 않으며 가상 메모리와 같은 시스템 리소스의 전환도 포함되지 않는다는 점에 유의해야 합니다. 이는 우리가 일반적으로 "프로세스 컨텍스트 전환"이라고 부르는 것과는 다릅니다. 프로세스 컨텍스트 전환은 시스템 호출 중에 동일한 프로세스가 항상 실행되는 동안 한 프로세스에서 다른 프로세스로 전환하는 것을 의미합니다

시스템 호출 프로세스는 컨텍스트 스위치가 아니라 권한 모드 스위치라고 불리는 경우가 많습니다. 하지만 실제로는 시스템 호출 과정에서 CPU 컨텍스트 스위칭도 불가피하다.

프로세스 컨텍스트 전환 vs 시스템 호출

그럼 프로세스 컨텍스트 전환과 시스템 호출의 차이점은 무엇인가요? 우선, 프로세스는 커널에 의해 관리되며 프로세스 전환은 커널 모드에서만 발생할 수 있습니다. 따라서 프로세스 컨텍스트에는 가상 메모리, 스택 및 전역 변수와 같은 사용자 공간 리소스뿐만 아니라 커널 스택 및 레지스터와 같은 커널 공간 상태도 포함됩니다.

그래서 프로세스 컨텍스트 전환에는 system call보다 한 단계 더 많은 단계가 있습니다.

현재 프로세스의 커널 상태와 CPU 레지스터를 저장하기 전에 프로세스의 가상 메모리, 스택 등을 저장하고 다음 프로세스의 커널 상태를 로드해야 합니다.

Tsuna의 테스트 보고서에 따르면 각 컨텍스트 전환에는 수십 나노초에서 마이크로초의 CPU 시간이 필요합니다. 이 시간은 상당하며, 특히 프로세스 컨텍스트 전환 수가 많은 경우 CPU가 레지스터, 커널 스택 및 가상 메모리와 같은 리소스를 저장하고 복원하는 데 많은 시간을 소비하게 만들 수 있습니다. 이것이 바로 지난 기사에서 이야기한 내용이며, 평균 부하를 높이는 중요한 요소입니다.

그럼 프로세스는 언제 CPU에서 실행되도록 예약/전환되나요? 실제로 많은 시나리오가 있습니다. 아래에 요약해 보겠습니다.

• 프로세스의 CPU 시간 조각이 종료되면 시스템에 의해 해당 프로세스가 일시 중지되고 CPU 실행을 기다리는 다른 프로세스로 전환됩니다. 시스템 리소스가 부족한 경우(예: 메모리 부족) 리소스가 충분할 때까지 프로세스를 실행할 수 없습니다. 이때 해당 프로세스도
일시중단
• 되며 시스템은 다른 프로세스 실행을 예약합니다. 프로세스가
함수를 통해 자동으로
• 일시 중지되면 sleep 자연스럽게 일정이 변경됩니다. 우선순위가 높은 프로세스가 실행 중인 경우, 우선순위가 높은 프로세스의 실행을 보장하기 위해 현재 프로세스는 우선순위가 높은 프로세스에 의해 일시중지됩니다
.
• 하드웨어 인터럽트가 발생하면 CPU의 프로세스는 인터럽트 일시 중단
되고 대신 커널에서 인터럽트 서비스 루틴을 실행합니다.
• 컨텍스트 전환으로 인해 성능 문제가 발생하면 이러한 시나리오가 배후의 킬러이기 때문에 이러한 시나리오를 이해하는 것이 매우 필요합니다.

스레드 컨텍스트 전환

스레드와 프로세스의 가장 큰 차이점은 스레드가 작업 스케줄링

의 기본 단위인 반면, 프로세스는

자원 획득의 기본 단위라는 것입니다. 직접 말하면 커널의 소위 작업 스케줄링은 실제로 스레드를 예약하고 프로세스는 스레드에 대한 가상 메모리 및 전역 변수와 같은 리소스만 제공합니다. 따라서 스레드와 프로세스의 경우 다음과 같이 이해할 수 있습니다.

프로세스에 스레드가 하나만 있으면 프로세스 하나는 스레드 하나와 같다고 생각할 수 있습니다

• 프로세스에 여러 스레드가 있는 경우 이러한 스레드는 가상 메모리 및 전역 변수와 같은 동일한 리소스를 공유합니다.
• 또한 스레드에는 컨텍스트 전환 중에 저장해야 하는 스택 및 레지스터와 같은 자체 개인 데이터도 있습니다.
• 이러한 방식으로 스레드 컨텍스트 전환은 실제로 두 가지 상황으로 나눌 수 있습니다.

우선, 전후의 두 스레드는 서로 다른 프로세스에 속합니다. 이때 자원을 공유하지 않으므로 전환 과정은 프로세스 컨텍스트 전환과 동일하다.

• 둘째, 전후의 두 스레드는 동일한 프로세스에 속합니다. 이때 가상 메모리는 공유되기 때문에 전환 시 가상 메모리 자원은 그대로 유지되며, 스레드의 프라이빗 데이터, 레지스터, 기타 공유되지 않는 데이터만 전환하면 됩니다.
• 분명히 동일한 프로세스 내에서 스레드를 전환하면 여러 프로세스를 전환하는 것보다 리소스를 덜 소비합니다. 이는 멀티 프로세스가 아닌 멀티 스레딩의 장점이기도 합니다.

인터럽트 컨텍스트 전환

앞의 두 컨텍스트 전환 외에도 CPU 컨텍스트 전환을 출력하는 또 다른 시나리오가 있는데, 바로 interrupt

입니다.

이벤트에 빠르게 응답하기 위해 하드웨어 인터럽트는 일반적인 일정 및 실행 프로세스를 중단한 다음 인터럽트 처리기

를 호출합니다.

다른 프로세스를 중단하는 경우 중단 후에도 프로세스를 원래 상태에서 복원할 수 있도록 프로세스의 현재 상태를 저장해야 합니다.

프로세스 컨텍스트와 달리 인터럽트 컨텍스트 전환에는 프로세스의 사용자 상태가 포함되지 않습니다. 따라서 인터럽트 프로세스가 사용자 모드에서 프로세스를 중단시키더라도 해당 프로세스의 가상 메모리, 전역 변수 등 사용자 모드 자원을 저장하고 복원할 필요가 없다.

또한 프로세스 컨텍스트 전환과 마찬가지로 인터럽트 컨텍스트 전환도 CPU를 소비합니다. 과도한 전환 시간은 많은 CPU 리소스를 소비하고 시스템의 전체 성능을 심각하게 저하시킵니다. 따라서 인터럽트가 너무 많다는 것을 알게 되면 시스템에 심각한 성능 문제를 일으킬 수 있는지 주의 깊게 살펴봐야 합니다.

결론

요약하자면 어떤 시나리오가 컨텍스트 전환으로 이어지든 다음 사항을 알아야 합니다.

CPU 컨텍스트 전환은 Linux 시스템의 정상적인 작동을 보장하는 핵심 기능 중 하나이며 일반적으로 특별한 주의가 필요하지 않습니다.

그러나 과도한 컨텍스트 전환은 레지스터, 커널 스택, 가상 메모리 등과 같은 데이터를 저장하고 복원하는 데 CPU 시간을 소비하므로 프로세스의 실제 실행 시간이 단축되고 전체 시스템 성능이 크게 저하됩니다.

위 내용은 Linux CPU에서 컨텍스트 전환 탐색의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!