☰

nice 레벨이 무시되는 이유는 무엇입니까? (다른 로그인 세션 사이 - 동일한 세션에서 시작하는 경우 좋습니다.)

tag-icon • tag-icon scheduling nice cpu-usage
nice 레벨이 무시되는 이유는 무엇입니까? (다른 로그인 세션 사이 - 동일한 세션에서 시작하는 경우 좋습니다.)

서로 다른 양호 수준으로 두 개의 CPU 소비 프로세스를 시작할 때, 예를 들어

프로세스 1:

nice -19 sh -c 'while true; do :; done'

프로세스 2:

sh -c 'while :; do true; done'

:true( 또는 의 출력에서 ​​프로세스를 구별하기 위해 및 의 순서를 변경했습니다 ),pstop

좋음 수준은 무시되고 둘 다 동일한 양의 CPU를 사용하는 것으로 보입니다.

top의 출력

  PID USER      PR  NI    VIRT    RES %CPU %MEM     TIME+ S COMMAND
 8187 <user>    39  19   21.9m   3.6m 45.8  0.0   0:20.62 R sh -c while true; do :; done
 8188 <user>    20   0   21.9m   3.5m 45.6  0.0   0:20.23 R sh -c while :; do true; done
 [...]

(물론 %CPU표본마다 그 값은 조금씩 다르지만 평균적으로는 동일한 것으로 나타난다.)

top이는 두 프로세스가 서로 다른 Nice 값으로 실행되고 있지만 여전히 동일한 CPU 시간을 얻는 것으로 나타납니다.

두 명령 모두 서로 다른 터미널(두 로그인 쉘)에서 동일한 사용자가 실행했습니다.

동일한 터미널에서 실행되면 예상대로 작동합니다. 더 나은 프로세스가 그다지 좋지 않은 프로세스에 양보합니다.

이유는 무엇입니까? 전체 기계의 전반적인 상황을 어떻게 잘 수행할 수 있습니까?

얼마 전까지만 해도 그 기계의 상황은 달라졌고 좋은 가치는 존중받는 것 같았습니다.

단일 프로세서/단일 코어 머신입니다.

자세한 내용은:

  • 커널: 버전 4.4.5(Arch Linux 기본 uname -r커널 )4.4.5-1-ARCH

  • /proc/cpuinfo예:

    processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Solo CPU    U3500  @ 1.40GHz
stepping        : 10
microcode       : 0xa0c
cpu MHz         : 1400.000
cache size      : 3072 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority
bugs            :
bogomips        : 2794.46
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

답변1

아, 각 사용자가 자신의 cgroup을 갖는 systemd-logind 기능이 아닙니다. 나는 여기에 관련된 변경 사항이 더 오래되었다고 생각합니다. 혼란스러울 정도로 유사합니다. (나는 "프로세스 그룹 공정한 스케줄링"을 검색했고 그것이 내가 실제로 이해하지 못한 유닉스 "프로세스 그룹"을 기반으로 한 것일 수도 있다고 생각했습니다.) 위키피디아:

Linux 커널은 2010년 11월에 2.6.38 커널용 CFS 패치를 받았으며, 이로 인해 스케줄러가 데스크톱 및 워크스테이션에서 사용하기에 더 적합해졌습니다.

작업이 __proc_set_tty()를 호출하면 기본 그룹에 대한 프로세스 전체 참조가 제거되고 새 작업 그룹이 생성되며 프로세스가 새 작업 그룹으로 이동됩니다. 그 후, 아이들은 작업 그룹을 상속받고 그 수를 다시 늘립니다. 종료 시 각 신호 구조에 대한 마지막 참조가 삭제되면 현재 작업 그룹에 대한 참조도 삭제됩니다. 작업 그룹을 참조하는 마지막 신호 구조가 해제되면 작업 그룹이 삭제됩니다. 대기열 선택을 실행할 때 작업에 cgroup이 할당되지 않은 경우 현재 자동 그룹이 사용됩니다.

CONFIG_SCHED_AUTOGROUP을 선택한 경우 이 기능은 부팅 시 기본적으로 활성화되지만 부팅 옵션 noautogroup을 통해 비활성화하거나 동적으로 켜거나 끌 수 있습니다.[via /proc/sys/kernel/sched_autogroup_enabled: 0거기에 쓰면 새로 생성된 작업이 비활성화되고 거기에 쓰면 1활성화됩니다. ]

이를 통해 해결되는 주요 문제는 멀티 코어 및 멀티 CPU(SMP) 시스템이 이러한 작업에서 많은 스레드를 사용하는 다른 작업을 수행할 때 대화형 응답 시간이 증가한다는 것입니다. 간단한 설명은 Linux 커널을 컴파일하거나 비디오 또는 유사한 프로세스를 인코딩하는 동안 결함이나 불안정 없이 비디오를 보고, 이메일을 읽고, 기타 일반적인 데스크톱 활동을 수행할 수 있다는 것입니다. 그러나 이 발언에 대한 반론도 있다.

관련 정보