☰

커널 스레딩이 전체 틱리스 모드를 방해하는 것 같습니까?

tag-icon • tag-icon linux kernel performance thread latency
커널 스레딩이 전체 틱리스 모드를 방해하는 것 같습니까?

대기 시간을 줄이기 위해 로컬 타이머 인터럽트를 비활성화하려고 합니다. 커널 구성에서 전체 노틱 모드를 활성화하고 관련 코어에 대해 부팅 매개변수 nohz_full을 설정했습니다.

그러나 /proc/interrupts를 통해 인터럽트 횟수를 보면 로컬 타이머 인터럽트가 코어당 초당 1000회씩 계산되는 것을 볼 수 있는데, 이는 완전히 틱리스가 작동하지 않는다는 의미입니다.

틱 없는 모드 문서에는 틱 없이 작동하려면 해당 코어에서 실행 중인 프로세스가 하나만 필요하다고 명시되어 있습니다.

상단을 보면 특정 코어(이 경우 코어 1) 아래에 다음이 표시됩니다.

   19 root      RT   0     0    0    0 S  0.0  0.0   0:00.00  1 watchdog/1
   20 root      -2   0     0    0    0 S  0.0  0.0   0:02.15  1 rcuc/1
   21 root      RT   0     0    0    0 S  0.0  0.0   0:00.04  1 migration/1
   22 root      -2   0     0    0    0 S  0.0  0.0   0:00.25  1 ksoftirqd/1
   23 root      RT   0     0    0    0 S  0.0  0.0   0:00.00  1 posixcputmr/1
   24 root      20   0     0    0    0 S  0.0  0.0   0:00.00  1 kworker/1:0
   25 root       0 -20     0    0    0 S  0.0  0.0   0:00.00  1 kworker/1:0H

나는 그들 중 일부가 커널 스레드라는 것을 알고 있습니다. 이것이 완전 틱리스 모드가 작동하지 않는 이유입니까?

답변1

예를 들어 활성화된 완전 틱리스 모드는 nohz_full=cpux-cpuy하나만 있는 경우에만 작동합니다.실행 가능각 CPU nohz_full의 작업 :

적응형 클러킹은 클록 예약이 필요하지 않은 다른 상황이 많더라도 특정 CPU에 대해 실행 가능한 작업이 하나만 없으면 아무 작업도 수행하지 않습니다.

(보다문서/타이머/NO_HZ.txt)

따라서 nohz_fullps를 사용하여 CPU를 확인하는 경우 실행 가능한 작업을 명시적으로 찾는 것이 좋습니다. 예를 들면 다음과 같습니다.

$ ps -e -L -o cpuid,pid,lwp,state,pri,rtprio,class,wchan:20,comm \
      | awk '$1 == '$mycpunr

(즉, 상태 표시줄을 보세요)

nohz_full이는 실행할 수 없는 한 CPU에 몇 가지 추가 작업이 있을 수 있음을 의미합니다 .

사용되는 한 nohz_full=커널이 선택한 CPU에서 사용자/커널 스레드를 예약하는 것을 방지하지 않습니다. 따라서 이러한 CPU는 일반적으로 다른 스레드의 간섭을 피하기 위해 격리됩니다. 예를 들어:

nohz_full=cpux-cpuy isolcpus=cpux-cpuy

(보다Linux 커널 매개변수)

nohz_full이러한 옵션을 사용하면 타이머 및 RCU 작업 등으로 인해 독립 CPU의 스레드가 계속 중단될 수 있습니다.

따라서 격리된 스레드의 대기 시간을 최소화하려면 다른 인터럽트 소스를 비활성화해야 합니다.

/proc/timer_list격리된 CPU에서 어떤 타이머가 아직 활성화되어 있는지 확인할 수 있습니다 .

격리된 CPU에 존재할 수 있는 타이머의 일반적인 예는 watchdog_timer_fnMCE(Machine Check Exception) 기능과 관련된 타이머입니다.

다음을 수행하여 이러한 인터럽트를 추가로 비활성화할 수 있습니다.커널 옵션,예를 들어:

nowatchdog mce=ignore_ce

카운터를 보는 것은 /proc/interrupts하드웨어로 인한 인터럽트를 확인하는 좋은 방법입니다. 인터럽트의 또 다른 원인은 Softirq이므로 /proc/softirqs카운터도 확인해야 합니다.

예를 들어 격리된 CPU에서 RCU 관련 인터럽트를 최소화하려면 RCU 콜백을 커널 스레드로 오프로드하고 이를 비격리형 CPU로 마이그레이션한 다음 커널 옵션을 추가하여 격리된 CPU가 콜백 스레드를 알리지 않도록 제외할 수 있습니다.

rcu_nocb_poll

이 옵션은 유효해야 rcu_nocbs=하지만 nohz_full=이미 rcu_nocbs=지정된 CPU를 암시합니다.

이러한 스레드의 CPU 선호도를 명시적으로 설정하여 오프로드된 RCU 콜백 스레드를 관리 CPU로 명시적으로 이동해야 합니다. Tuna를 예로 들어 보겠습니다(CPU 0).

# tuna -U -t 'rcu*' -c 0 -m

커널 문서document/kernel-per-CPU-kthreads.txt추가 인터럽트 소스(운영 체제 스래싱이라고도 함)를 설명하고 추적이 활성화된 상태에서 테스트 로드를 실행하여 인터럽트를 찾는 방법을 보여줍니다.

관련 정보