프로세스 상태 관리
실행대기(Task_Running) 상태에 있는 프로세스 중 하나를 선택해서 CPU 실행(Task_Running)상태로 바꿔주는 동작
컨텍스트 스위칭
- CPU에서 실행 중인 E 프로세스의 실행 정보로 채워져 있는 CPU레지스터 Set를 비운다.
- A 프로세스의 레지스터 세트를 다시 CPU 코어 레지스터에 채운다.
시스템 콜
시스템 콜은 유저모드에서 커널 모드로 진입하는 동작이며,
유저 공간과 커널 공간 사이의 가상 계층이자 인터페이스 이다.
커널 공간이란?
- 커널 코드가 실행될 때는 커널 내부의 모든 함수 호출이 가능
- 제약 없이 메모리 공간에 접근해서 하드웨어를 제어
유저 공간이란?
- 유저 애플리케이션 코드가 구동하는 동작과 상태
- 유저 애플리케이션은 유저 공간에서 실행되며 메모리 공간 접근에 제한이 있어 하드웨어에 직접 접근할 수 없음
시스템 콜은 누가 언제 발생시킬까?
- 시스템 콜은 유저모드에서 동작 중인 애플리케이션에서 커널에게 어떤 서비스를 요청할 때 실행
- 유저 애플리케이션에서는 다음과 같은 상황에서 규약에 맞게 커널에 서비스를 요청
- 파일 시스템에 접근해서 파일을 읽거나 쓰고 싶을 때
- PID같은 프로세스 정보를 얻으려 할 때
- 시스템 정보를 얻고 싶을 때
시스템 콜 동작을 왜 잘 알아야 할까?
문제 해결능력을 키울 수 있다!
- 리눅스 시스템 프로그래밍을 하다 보면 리눅스 표준 함수를 호출했는데 가끔 에러를 반환함
- 시스템 콜이 유저 공간에서 커널 공간까지 어떤 흐름으로 동작하는지 잘 알면 어디서부터 분석을 시작해야 할지 알 수 있다.
ftrace로 디버깅하면 시스템 콜을 실행할 때의 세부적인 인자와 반환값을 알 수 있다!
안정적인 코드를 작성할 수 있다!
시스템 콜의 전체 흐름 파악하기
- 시스템 콜의 전체 흐름
시그널
- 프로세스에게 전달하는 간단한 형태의 메시지
- 주로 특정 프로세스를 종료할 때 많이 쓰임
커널 입장 : 시그널은 프로세스에게 보내는 단순한 형태의 메시지
시그널 정보와 PID를 프로세스에게 전달함
유저 프로세스 입장 : 시그널은 실행 흐름을 제어하는 비동기적인 중단유저 프로세스 입장에서 시그널 동작
시그널 번호와 동작 방식
시그널을 받으면 프로세스는 어떻게 동작할까?
- 프로세스가 시그널을 받아 동작하는 방식은 우리가 이메일을 받았을 때와 비슷하다.
- 시그널을 전달받은 프로세스가 이를 처리하는 방식
- 1번째 방식 : 시그널을 무시한다.
- 2번째 방식 : 시그널에 명시된 동작을 수행한다.
리눅스 커널에서 시그널을 처리하는 과정
- 1단계 : 시그널 생성
-wake_up_process()함수 호출해 시그널을 받을 프로세스를 깨움
- 2단계 : 시그널을 받아 처리
- syscall이나 interrupt 처리를 마무리한 후 시그널을 받아 처리함
유저 애플리케이션에서 시그널 핸들러를 설정했을 경우
커널은 시그널 핸들러를 호출만 한다.
유저 애플리케이션에서 시그널 핸들러를 설정하지 않았을 경우
커널은 시그널 타입에 따라 프로세스를 달리 처리한다.
ftrace의 시그널 이벤트 소개
ftrace는 시그널 동작에 대해 다음 이벤트를 지원
signal_generate: 시그널 생성signal_deliver: 프로세스가 시그널을 전달 받음
시그널 관련 이벤트는 다음 명령어로 활성화
echo 1>/sys/kernel/debug/tracing/events/signal/signal_generate/enable
echo 1>/sys/kernel/debug/tracing/events/signal/signal_deliver/enable메시지의 의미와 메시지를 출력하는 함수의 이름
| 이벤트 | 역할 | 시그널 ftrace 실행 함수 |
|---|---|---|
| signal_generate | 시그널 생성 | __send_signal() / send_sigqueue() |
| signal_deliver | 시그널을 받아 처리 | get_signal() |
