작성
·
37
0
커널 코드 실행 중 인터럽트가 발생한 경우에는 thread_info 구조체의 preemption_count 값을 통해 preemptive schedule 가능 여부를 판단하고, 유저 코드 실행 중에 발생한 경우에는 flags 값을 통해 preemptive schedule 가능 여부를 판단하는 것을 이해했는데, 둘이 왜 확인 방법이 다른지 궁금합니다
답변 2
0
확인 방법이 다른 이유는 인터럽트가 유발된 후 유저 공간으로 복귀하는 프로세스와 커널 공간에서 실행되는 프로세스의 Preemption을 다른 방식으로, 유연하게 처리하기 위해서입니다.
리눅스 커널에서는 기본적으로 CFS 스케줄러에 의해 프로세스의 실행 시간이 관리되는데, 프로세스에게 일정 시간 실행될 수 있는 timeslice를 제공합니다. timeslice를 프로세스가 다 소진했을 때는 preemption될 대상이 되며, 아래와 같이 설정됩니다.
유저 프로세스인 경우 flags를 TIFNEED_RESCHED 로 설정
커널 공간에서 실행되는 프로세스인 경우 preempt_count를 0으로 설정
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다.
이진후님, 문의 주신 주제에 대해 설명드리겠습니다.
리눅스 커널에서 preemption을 체크하는 방법은 실행 문맥(context)에 따라 달라집니다. 이는 커널 코드와 사용자 코드의 실행 환경이 다르기 때문입니다.
커널 코드 실행 중: thread_info
구조체의 preemption_count
값을 확인합니다. 이는 커널에서의 작업이 인터럽트될 수 있는지를 나타내는 값입니다. 커널 모드에서는 더욱 세밀한 제어가 필요하기 때문에, 다양한 플래그를 가진 preemption_count
를 사용하여 preemption을 켜거나 끌 수 있습니다. 이를 통해 보다 유연하고 세밀한 스케줄링 제어가 가능합니다.
유저 코드 실행 중: 사용자 모드에서는 보통 flags
값을 사용하여 preemption 여부를 판단합니다. 이는 일반적으로 커널과는 다른 방식으로 수행되며, 커널 모드처럼 세밀한 스케줄링 제어가 필요하지 않기 때문입니다. 사용자 모드에서는 상대적으로 간단한 방식으로 preemption을 관리합니다.
이 두 경우의 차이는 결국 실행 권한과 환경의 차이로 인해 발생하는 것입니다. 커널 모드는 특수한 환경설정이 필요하고, 사용자 모드는 그에 비해 간단한 방식으로 동작하도록 설계되어 있습니다.
추가적으로 궁금한 점이 있으시면 언제든지 질문해 주세요!
이미지 출처 및 추가 정보:
링크