Windows의 「프로세서 스케줄링」을 「백그라운드 서비스」로 바꾸면 무슨 일이 일어나는가 - quantum, 우선도 부스트, P 코어 / E 코어까지 정리

「앱을 전면에서 빼면 소리가 지직거린다」
「프로세서 스케줄링을 백그라운드 서비스로 하면 안정됐다」

Windows에서는 예전부터 이런 이야기가 나옵니다. 특히 오디오, 영상, 계측, 배포, 상주 처리처럼 UI보다 연속 처리가 더 중요한 장면에서는 신경 쓰입니다.

다만 이 설정은 마법의 고속화 스위치가 아닙니다. CPU의 클럭을 직접 올리는 설정도, 앱을 Windows 서비스로 바꾸는 설정도, P 코어로 고정하는 설정도 아닙니다. 주로 바뀌는 것은 전면 앱과 배후에서 도는 처리 사이에서 CPU 시간을 어떻게 나누는가입니다.

flowchart TB
    accTitle: 이 설정이 바꾸는 것
    accDescr: 프로세서 스케줄링 설정은 클럭을 올리는 설정도 서비스화나 P 코어 고정의 설정도 아니라 전면 앱과 배후 처리 사이의 CPU 시간 배분 방식을 바꾸는 설정임을 보여주는 그림.
    st1["프로세서 스케줄링 설정"] -.->|"이것들은 바꾸지 않는다"| notx["클럭·서비스화·코어 고정"]
    st1 -->|"바꾸는 것은"| shr1["전면과 배후로의 CPU 시간 배분"]

그림 1: 고속화 스위치가 아니라 CPU 시간 배분 방식을 바꾸는 설정으로 읽는다.

이 글에서는 프로그램과 백그라운드 서비스로 무엇이 바뀌는지를 Windows 스케줄러의 기본, quantum(타임 슬라이스), foreground의 우대, 그리고 P 코어 / E 코어를 가진 CPU의 동작까지 이어서 정리합니다.

1. 먼저 결론

결론만 먼저 나열하면 포인트는 다음입니다.

• 이 설정이 직접 바꾸는 것은 CPU의 「마력」보다 CPU 시간의 「배분 방식」입니다.
• 프로그램은 전면 앱을 우대하기 쉽고, 백그라운드 서비스는 전면과 배후의 처리를 더 균등하게 다루는 방향입니다.
• 그래서 전면 UI보다 뒤에서 도는 연속 처리의 마감이 중요한 워크로드에서는 백그라운드 서비스가 효과가 있을 수 있습니다.
• 다만 P 코어 / E 코어 CPU에서 「어느 코어에 올리는가」는 이제는 이 설정뿐만 아니라 QoS, 전원 정책, hybrid scheduling, Intel Thread Director 같은 것들이 더 강하게 작용합니다.
• 즉 백그라운드 서비스로 했다고 해서 「배경 처리는 P 코어로」, 「서비스는 E 코어로」 같은 단순한 이야기가 되지는 않습니다.
• 오디오의 지직거림이나 드롭아웃이 DPC / ISR, USB 절전, 드라이버, thermal throttling, EcoQoS 유래라면, 이 설정만으로는 고쳐지지 않습니다.

한마디로 이 설정은 CPU의 주파수 설정이 아니라 줄 서기의 규칙을 바꾸는 설정입니다.

flowchart TB
    accTitle: 효과가 있는 것과 없는 것의 큰 그림
    accDescr: 뒤에서 도는 연속 처리의 마감이 중요한 워크로드에는 백그라운드 서비스 쪽이 효과가 있을 수 있는 한편, P 코어/E 코어 중 어디에 올라가는가는 QoS나 전원 정책 등이 더 강하게 작용함을 보여주는 그림.
    bgss1["백그라운드 서비스 쪽"] -->|"효과가 있을 수 있다"| dl1["뒤의 연속 처리 마감"]
    bgss1 -.->|"정하는 것은 다른 구조"| core1["P 코어 / E 코어 선택"]
    core1 --> qos1["QoS·전원 정책·hybrid scheduling"]

그림 2: 마감에는 효과가 있을 수 있지만, 코어 선택은 이 설정 밖의 구조가 정한다.

1.1 먼저 짚어 둘 용어

이 글에서는 6장쯤 읽어야 실체를 알 수 있는 용어가 앞부분에 먼저 나옵니다. 미리 정리해 둡니다.

이 글의 지식 맵

프로세서 스케줄링 설정은 내부적으로 Win32PrioritySeparation이라는 레지스트리 값과 연결되어, foreground와 background에 나눠 주는 quantum의 길고 짧음과 우대 정도를 전환할 뿐이며, CPU의 클럭이나 코어 고정을 직접 바꾸는 설정이 아닙니다. 백그라운드 서비스 쪽은 전면 우대를 약화시키기 때문에, 마감에 쫓기는 음성 처리 등의 underrun을 줄이는 경우가 있지만, 이는 MMCSS가 담당하는 우선도 인상과는 별개의 구조입니다. 현대의 Windows, 특히 P 코어 / E 코어의 hybrid CPU에서는 실제로 어느 코어에 배치되는지가 이 설정보다 Windows QoS나 Intel Thread Director를 사용하는 heterogeneous scheduling 정책 쪽이 더 강하게 작용하며, 최소화나 배터리 구동만으로도 QoS가 내려가 efficient core 쪽에 놓이는 경우도 있습니다. 원인을 파악하려면 DPC/ISR 지연을 Windows Performance Recorder와 Analyzer로 관측하는 절차가 효과적입니다.

flowchart LR
    accTitle: 프로세서 스케줄링 설정과 QoS의 지식 맵
    accDescr: 프로세서 스케줄링 설정이 Win32PrioritySeparation과 연결되어 quantum 배분·foreground 우대를 전환하는 오래된 구조라는 것, MMCSS나 Windows QoS가 underrun이나 P 코어 / E 코어 배치에 효과가 있다는 것, Intel Thread Director나 heterogeneous scheduling 정책이 hybrid CPU의 코어 선택을 결정한다는 것, DPC/ISR 지연 확인 수단을 보여주는 그림
    processor_scheduling_setting["프로세서 스케줄링 설정"]
    windows_qos["Windows QoS(서비스 품질) 분류"]
    win32priorityseparation["Win32PrioritySeparation"]
    quantum["quantum(타임 슬라이스)"]
    foreground_boost["포그라운드 우대"]
    audio_underrun["언더런(underrun)"]
    mmcss["MMCSS(Multimedia Class Scheduler Service)"]
    efficient_core_placement["efficient core 위주 배치"]
    ecoqos["EcoQoS"]
    disableuserpresenceqos["DisableUserPresenceQos"]
    hybrid_scheduling_policy["heterogeneous scheduling 정책(SchedulingPolicy 등)"]
    intel_thread_director["Intel Thread Director"]
    p_core_e_core_cpu["P코어/E코어 구성(하이브리드 CPU)"]
    core_parking["Core Parking"]
    dpc_isr_latency["DPC/ISR 지연"]
    wpr_wpa["WPR/WPA(Windows Performance Recorder/Analyzer)"]
    processor_scheduling_setting -->|"에서 구성할 수 있다"| win32priorityseparation
    quantum -->|"에서 구성할 수 있다"| win32priorityseparation
    processor_scheduling_setting -->|"이용한다"| quantum
    processor_scheduling_setting -->|"이용한다"| foreground_boost
    processor_scheduling_setting -.->|"완화한다"| audio_underrun
    mmcss -->|"완화한다"| audio_underrun
    mmcss -->|"이용한다"| windows_qos
    windows_qos -.->|"원인이 될 수 있다"| efficient_core_placement
    ecoqos -->|"원인이 될 수 있다"| efficient_core_placement
    disableuserpresenceqos -.->|"방지한다"| efficient_core_placement
    hybrid_scheduling_policy -->|"이용한다"| windows_qos
    hybrid_scheduling_policy -.->|"이용한다"| intel_thread_director
    hybrid_scheduling_policy -->|"전제로 한다"| p_core_e_core_cpu
    intel_thread_director -->|"전제로 한다"| p_core_e_core_cpu
    hybrid_scheduling_policy -->|"이용한다"| core_parking
    dpc_isr_latency -->|"에서 확인할 수 있다"| wpr_wpa
    p_core_e_core_cpu -->|"에서 확인할 수 있다"| wpr_wpa
    dpc_isr_latency -.->|"원인이 될 수 있다"| audio_underrun

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 18건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 애초에 이 설정은 무엇을 바꾸고 있는가

설정 화면의 프로세서 스케줄링은 Windows에 예전부터 있는 스케줄링 방침 중 하나입니다. 내부적으로는 Win32PrioritySeparation과 연결된, 꽤 역사가 있는 설정입니다.

여기서 먼저 짚어 두고 싶은 것은 Windows가 CPU를 사용할 때의 기본입니다.

• 스케줄러는 먼저 실행 가능한 스레드 중에서 우선도가 높은 것을 고릅니다.
• 같은 우선도라면 일정 시간씩 순서대로 실행합니다.
• 이 「일정 시간」이 quantum(타임 슬라이스)입니다.

flowchart LR
    ready["실행 가능한 스레드"] --> pick["스케줄러가 최우선 스레드를 고른다"]
    pick --> run["1 quantum만큼 실행한다"]
    run --> wait{"같은 우선도의 대기 스레드가 있는가"}
    wait -- yes --> switch["컨텍스트 스위치"]
    switch --> pick
    wait -- no --> run

그림 3: 스케줄러는 최우선 스레드를 고르고, 1 quantum씩 순서대로 달리게 한다.

프로세서 스케줄링이 주로 건드리고 있는 것은 이 quantum의 배분 방식과 foreground를 얼마나 우대할 것인가입니다.

여기서 말하는 foreground는 지금 사용자가 다루고 있는 전면 앱입니다. 반대로 뒤로 돌아간 처리, 다른 프로세스의 worker, Windows 서비스, 보조 프로세스, 상주 처리 등은 background 쪽으로 기울기 쉬워집니다.

중요한 것은 백그라운드 서비스를 골라도 자신의 앱이 Windows 서비스가 되는 것은 아니라는 점입니다. 바뀌는 것은 서비스라는 이름의 종류가 아니라 foreground와 background의 CPU 배분 규칙입니다. 여기, 이름이 꽤 헷갈립니다.

flowchart TB
    accTitle: 「백그라운드 서비스」라는 이름의 헷갈림
    accDescr: 백그라운드 서비스를 골라도 자신의 앱이 Windows 서비스가 되는 것은 아니며, 바뀌는 것은 foreground와 background의 CPU 배분 규칙뿐임을 보여주는 그림.
    sel2["백그라운드 서비스를 고른다"] -.->|"이렇게는 되지 않는다"| svcx["앱이 Windows 서비스가 된다"]
    sel2 -->|"바뀌는 것은"| rule1["전면과 배후의 CPU 배분 규칙"]

그림 4: 이름과 달리, 바뀌는 것은 프로세스의 종류가 아니라 배분 규칙 쪽이다.

2.1 설정 화면까지 가는 길

이 설정은 제어판 상당히 깊은 곳에 있습니다. 도달 경로는 2가지입니다.

• Win + R에서 SystemPropertiesPerformance.exe를 실행하면 「성능 옵션」이 바로 열립니다. 그 「고급」 탭에 프로세서 스케줄링이 있습니다.
• 손으로 따라가려면 「시스템 속성」 > 「고급」 탭 > 「성능」의 「설정」 > 「고급」 탭 순서입니다. 「시스템 속성」 자체는 sysdm.cpl로 열 수 있습니다.

고른 결과는 레지스트리의 다음 값에 기록됩니다.

현재 값만 확인하고 싶다면 PowerShell로 읽을 수 있습니다. 설정을 되돌릴 수 있도록 변경 전 값은 적어 두는 것이 안전합니다.

flowchart TB
    accTitle: UI 선택과 레지스트리의 관계
    accDescr: 성능 옵션 UI에서 고른 결과는 Win32PrioritySeparation이라는 레지스트리 값에 기록되고, 현재 값은 PowerShell로 읽을 수 있으므로 변경 전 값을 적어 두고 나서 건드린다는 흐름을 보여주는 그림.
    uix2["UI에서 선택한다"] --> regw1["Win32PrioritySeparation에 기록된다"]
    regw1 --> pr1["PowerShell로 현재 값을 읽을 수 있다"]
    pr1 -.-> keep2["변경 전 값을 적어 두고 나서 바꾼다"]

그림 5: UI 선택의 실체는 레지스트리 값이므로, 건드리기 전에 현재 값을 적어 둔다.

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\PriorityControl' -Name 'Win32PrioritySeparation'

2.2 대상이 되는 Windows와 값의 의미

「성능 옵션」의 프로세서 스케줄링은 Windows 10 / Windows 11 클라이언트에도, Windows Server에도 있습니다. 다만 같은 값이라도 클라이언트와 서버에서 해석이 다르다는 점이 이 설정을 헷갈리게 만듭니다.

Microsoft의 레지스트리 해설에서는 Win32PrioritySeparation이 6비트를 2비트씩 3묶음(AABBCC)으로 나눈 비트마스크라고 설명합니다.

• 상위 2비트: quantum이 길게인지 짧게인지
• 중위 2비트: quantum이 가변인지 고정인지
• 하위 2비트: foreground를 background의 몇 배 우대할지(가변일 때만 적용)

그리고 UI에서의 선택이 각각 다음 값을 기록한다고 되어 있습니다(당시의 UI 표기는 Applications와 Background services로, 지금의 프로그램과 백그라운드 서비스에 대응합니다).

수치를 한 걸음 더 들어가 보면, Microsoft의 해설 기사에서는 0x26일 때의 quantum이 foreground 18, background 6, 0x18일 때는 양쪽 다 36이라고 설명합니다. quantum은 clock tick의 3분의 1 단위이므로 tick으로 환산하면 전면 6 tick / 배후 2 tick과 양쪽 다 12 tick이 됩니다. 같은 기사에서는 x86 멀티프로세서 머신의 clock tick이 15.625밀리초였던 예가 나와 있으며, 이 경우 「전면이 약 94밀리초까지 연속으로 달리는 설정」과 「전면도 배후도 약 188밀리초씩 달리는 설정」의 차이가 됩니다.

즉 백그라운드 서비스 쪽은 한 번에 달리는 시간은 길지만 전면만 편애하지 않는 배분 방식입니다. 배후 처리가 「순서가 돌아오지 않는」 상태가 되기 어려워집니다.

flowchart TB
    accTitle: 두 설정에서의 quantum 배분 방식
    accDescr: 프로그램 설정에서는 전면이 6 tick, 배후가 2 tick으로 전면이 길게 달리고, 백그라운드 서비스 설정에서는 양쪽 다 12 tick씩으로 한 번에 달리는 시간은 길지만 전면만 편애하지 않는 배분 방식이 됨을 보여주는 그림.
    pg1["프로그램 설정"] --> fg6["전면 6 tick·배후 2 tick"]
    bg2["백그라운드 서비스 설정"] --> eq12["전면도 배후도 12 tick"]
    eq12 --> nofam1["배후에 순서가 돌아오지 않는 상태가 되기 어렵다"]

그림 6: 한쪽은 전면을 길게 달리게 하고, 다른 쪽은 긴 지속 시간을 균등하게 배분한다.

참고로 이 기본값의 해석에도 OS 차이가 있습니다. Microsoft의 Win32_OperatingSystem 설명에서는 클라이언트 Windows가 가변 길이 quantum으로 전면 앱의 quantum이 길다, Windows Server는 고정 길이 quantum이 기본이라고 되어 있습니다. 레지스트리 해설 쪽도 같은 기본값 0x2가 클라이언트에서는 「짧은 편·가변·전면 3배」, 서버에서는 「긴 편·고정·균등」을 의미한다고 적고 있습니다. 서버가 처음부터 백그라운드 서비스에 준하는 쪽으로 기울어 있는 것은 이 때문입니다.

flowchart TB
    accTitle: 같은 기본값이라도 클라이언트와 서버에서 해석이 다르다
    accDescr: 같은 기본값이라도 클라이언트 Windows에서는 짧은 편·가변·전면 3배 우대, Windows Server에서는 긴 편·고정·균등으로 해석되며, 서버가 처음부터 백그라운드 서비스에 준하는 쪽으로 기울어 있음을 보여주는 그림.
    dv1["같은 기본값"] -->|"클라이언트"| cl2["짧은 편·가변·전면 3배"]
    dv1 -->|"서버"| sv4["긴 편·고정·균등"]
    sv4 -.-> lean1["처음부터 백그라운드 서비스에 준함"]

그림 7: 값 자체가 아니라 OS 쪽이 기본 해석을 가른다.

여기서 든 구체적인 수치는 Windows 2000 / XP 세대의 Microsoft 문서와 해설 기사에 근거한 것입니다. 레지스트리 값과 UI의 대응은 지금도 같지만, 실제 quantum의 취급은 OS 버전에 따라 달라질 수 있으므로 수치는 「어느 정도 자릿수의 이야기인지」의 기준으로 읽어 주십시오.

3. 프로그램과 백그라운드 서비스로 무엇이 바뀌는가

양자의 차이는 표로 비교해 보면 이해하기 쉽습니다.

클라이언트용 Windows는 기본적으로 전면 앱을 쾌적하게 움직이는 방향입니다. 그래서 보통의 데스크톱 조작에서는 프로그램이 자연스럽습니다.

한편으로 이야기가 달라지는 경우도 있습니다.

• 뒤에서 계속 버퍼를 채우는 오디오 처리
• UI는 가볍지만 별도 스레드 / 별도 프로세스에서 계속 실행되는 캡처나 분석
• 전면에 브라우저나 IDE를 띄워도 뒤 처리의 마감을 지키고 싶은 경우
• 서버 쪽, 서비스 쪽, 상주 쪽 워크로드

이럴 때는 foreground만 강하게 우대하기보다 뒤의 처리가 CPU를 되찾기 쉬운 편이 안정적입니다. 그런 의미에서 백그라운드 서비스는 이치에 맞는 경우가 있습니다.

flowchart TB
    accTitle: 어느 배분 방식이 맞는가
    accDescr: 대화 중심의 데스크톱 조작이라면 전면 우대의 프로그램 설정이 자연스럽고, 뒤의 연속 처리 마감이 중요한 워크로드라면 뒤가 CPU를 되찾기 쉬운 백그라운드 서비스 설정이 이치에 맞음을 보여주는 그림.
    wl1["워크로드의 성격"] -->|"대화 중심의 조작"| pgn1["프로그램이 자연스럽다"]
    wl1 -->|"뒤의 마감이 중요"| bgn1["백그라운드 서비스가 후보"]
    bgn1 --> back2["뒤의 처리가 CPU를 되찾기 쉽다"]

그림 8: 전면의 쾌적함과 뒤의 마감 중 어느 쪽을 지킬지에 따라 고를 쪽이 달라진다.

4. 왜 음성이나 연속 처리에서 효과가 있을 때가 있는가

오디오의 지직거림이나 드롭아웃을 예로 들면 이해하기 쉽습니다.

음성 처리는 「평균적으로 빠른」 것만으로는 부족합니다. 수 밀리초마다, 혹은 더 짧은 단위로 필요한 타이밍까지 버퍼를 채울 필요가 있습니다. 평균 CPU 사용률이 낮아도 마침 그 순간에 달리지 못하면 소리가 끊깁니다.

구체적인 상황을 하나 들어 보겠습니다.

• 전면에는 브라우저나 DAW의 UI, 또는 다른 앱이 있다
• 뒤에서는 음성 처리 스레드가 일정 주기로 돌면서 버퍼를 공급하고 있다
• 음성 처리 스레드는 고우선도까지는 아니고, MMCSS나 QoS도 충분히 쓰지 못하고 있다
• CPU가 그럭저럭 붐비고 있다

이때 프로그램이라면 전면 앱 쪽이 길게 달리기 쉬워, 뒤의 음성 처리가 「평균으로는 문제없는데 그 순간만 늦어지는」 일이 있을 수 있습니다. 이것이 이어지면 underrun이 되어 지직거림으로 이어집니다.

반대로 백그라운드 서비스로 돌리면 뒤의 연속 처리가 CPU를 되찾기 쉬워져 마감을 놓치기 어려워지는 경우가 있습니다.

즉 효과가 있을 때 일어나고 있는 것은 「CPU가 빨라졌다」가 아니라,

• 전면 앱의 우대가 조금 약해진다
• 뒤의 연속 처리가 끼어들 수 있는 횟수나 타이밍이 개선된다
• 결과적으로 deadline miss가 줄어든다

라는 흐름입니다.

flowchart TB
    accTitle: 소리의 지직거림이 줄어드는 흐름
    accDescr: 프로그램 설정에서는 전면이 길게 달려 뒤의 음성 처리가 그 순간만 늦어져 underrun이 될 수 있고, 백그라운드 서비스로 돌리면 전면 우대가 약해져 뒤가 끼어들기 쉬워지고 deadline miss가 줄어드는 흐름을 보여주는 그림.
    fgl1["전면이 길게 달린다"] --> late1["음성 처리가 그 순간만 늦어진다"]
    late1 --> ur1["underrun으로 지직거림"]
    even2["배분 방식을 균등 쪽으로 돌린다"] --> take1["뒤가 끼어들기 쉬워진다"]
    take1 --> less1["deadline miss가 줄어든다"]

그림 9: 효과가 있을 때는 CPU가 빨라진 것이 아니라, 뒤의 처리가 마감에 맞게 되는 것이다.

5. 원리 - quantum과 foreground의 우대

조금 더 로우 레벨 쪽에서 보면, 효과가 나는 경위는 이렇습니다.

5.1 quantum이 길면 같은 우선도의 상대는 기다리기 쉽다

같은 우선도대에서 경쟁하는 스레드가 여럿일 때, 한 스레드가 긴 quantum을 받을수록 다른 스레드는 그만큼 기다리기 쉬워집니다.

전면 앱이 우대되는 설정에서는 foreground 쪽이 길게 연속 실행하기 쉬워집니다. 그러면 비슷한 우선도인 background 쪽은 그만큼 「지금은 아니다」를 당하기 쉬워집니다.

음성, 영상, 주기 계측, 폴링, 감시처럼 조금씩이라도 정기적으로 달리고 싶은 처리에서는 이 차이가 영향을 줍니다.

flowchart TB
    accTitle: 긴 quantum이 동급 상대를 기다리게 한다
    accDescr: 같은 우선도대에서 경쟁하는 스레드가 여럿일 때, 한쪽이 긴 quantum을 받을수록 다른 스레드는 기다리기 쉬워지고, 조금씩이라도 정기적으로 달리고 싶은 처리에서는 이 차이가 영향을 줌을 보여주는 그림.
    comp1["같은 우선도대에서 경쟁하고 있다"] --> long1["한쪽이 긴 quantum을 받는다"]
    long1 --> wt2["다른 스레드는 기다리기 쉽다"]
    wt2 -.-> perio1["정기적으로 달리고 싶은 처리일수록 차이가 난다"]

그림 10: quantum의 길이는 동급으로 경쟁하는 상대의 대기 시간으로 그대로 되돌아온다.

5.2 Windows는 foreground에 여러 형태로 신경 쓴다

Windows는 원래 foreground에 상당히 신경을 씁니다. 대표적인 것은 다음과 같습니다.

• 전면에 온 프로세스의 우대
• 입력을 받은 윈도우를 가진 스레드의 우대
• I/O 완료 후 스레드에 대한 동적 우선도 부스트

즉 앱을 전면에서 빼는 것만으로도 스케줄링상의 취급은 평범하게 바뀝니다. 백그라운드 서비스는 이 foreground 우대 중에서도 특히 CPU 시간 배분의 편향을 줄이는 방향이라고 생각하면 이해하기 쉽습니다.

flowchart TB
    accTitle: Windows가 foreground에 신경 쓰는 방식
    accDescr: Windows는 전면에 온 프로세스의 우대, 입력을 받은 윈도우의 스레드 우대, I/O 완료 후의 동적 우선도 부스트 등 여러 방식으로 foreground에 신경 쓰기 때문에, 전면에서 빼는 것만으로 취급이 바뀜을 보여주는 그림.
    fgc1["전면 프로세스의 우대"] --> chg2["전면에서 빼는 것만으로 취급이 바뀐다"]
    fgc2["입력 윈도우의 스레드 우대"] --> chg2
    fgc3["I/O 완료 후의 동적 부스트"] --> chg2
    chg2 -.-> shrink1["이 설정은 배분의 편향을 줄이는 쪽"]

그림 11: 전면 우대는 여러 장치가 겹친 결과이며, 이 설정은 그중 배분 편향에 작용한다.

5.3 「CPU를 게으르게 두지 않는다」는 반은 맞고 반은 어긋난다

「CPU를 게으르게 두지 않는다」는 표현은 감각적으로는 이해가 갑니다. 뒤의 처리가 뒤로 밀리기 어렵다는 의미에서는 확실히 그렇습니다.

다만 기술적으로는 조금 더 정확하게 말하는 편이 좋으며, 실제로 바뀌고 있는 것은 CPU의 idle 제어나 주파수 그 자체보다 스레드를 어떤 순서로, 얼마만큼의 길이로 달리게 하는가입니다.

그래서 이 설정은,

• turbo boost를 올리는 설정이 아니다
• C-state를 끄는 설정이 아니다
• core parking을 직접 바꾸는 설정이 아니다
• P 코어 고정 설정이 아니다

라는 것이 됩니다.

flowchart TB
    accTitle: 「게으르게 두지 않는다」의 정확한 의미
    accDescr: 이 설정으로 실제로 바뀌는 것은 CPU의 idle 제어나 주파수가 아니라 스레드를 어떤 순서로 얼마만큼 달리게 하는가이며, turbo나 C-state, core parking, P 코어 고정의 설정이 아님을 보여주는 그림.
    sabo1["CPU를 게으르게 두지 않는다, 는 감각"] -->|"실제로 바뀌는 것은"| ord2["달리는 순서와 길이"]
    sabo1 -.->|"바뀌지 않는 것은"| pw2["turbo·C-state·core parking·코어 고정"]

그림 12: 「게으르게 두지 않는다」의 실체는 전력 제어가 아니라 순서와 지속 시간의 변경에 있다.

6. P 코어 / E 코어 CPU에서는 어떻게 효과가 있는가

여기가 가장 오해되기 쉬운 부분입니다.

백그라운드 서비스로 했다고 해서 Windows가 「배경 처리니까 E 코어」, 「전면이니까 P 코어」라고 단순하게 정하는 것은 아닙니다. 현대의 Windows, 특히 Windows 11의 hybrid CPU에서는 P 코어 / E 코어의 선택이 더 다단계입니다.

6.1 이름은 비슷하지만 별개

먼저 비슷한 이름의 별개인 것이 2가지 있습니다.

1. 프로세서 스케줄링의 백그라운드 서비스
   • 오래된 UI에 있는 설정
   • 주로 foreground / background의 CPU 시간 배분에 작용
   • quantum과 foreground boost 계통의 이야기
2. QoS의 Utility / Eco / Low 등
   • 현대 Windows의 power / performance 분류
   • core 선택이나 주파수 제어에도 작용
   • P 코어 / E 코어의 동작에 직접 관련되기 쉽다

이 2가지는 같지 않습니다.

flowchart TB
    accTitle: 이름은 비슷하지만 별개인 것
    accDescr: 프로세서 스케줄링 설정은 오래된 UI의 설정으로 quantum과 foreground 우대 계통에 작용하고, QoS는 현대의 power/performance 분류로 코어 선택과 주파수 제어에 작용하는 별개임을 보여주는 그림.
    old2["프로세서 스케줄링 설정"] --> qt1["quantum과 foreground 우대 계통"]
    newq1["QoS 분류"] --> cs2["코어 선택·주파수 제어 계통"]
    old2 -.->|"같지 않다"| newq1

그림 13: 이름의 느낌은 비슷해도, 작용하는 레이어가 완전히 다르다.

6.2 Windows 11의 QoS와 visibility

현대의 Windows에서는 priority뿐만 아니라 QoS도 작용합니다. 특히 heterogenous processor, 즉 P 코어 / E 코어 같은 구성에서는 QoS가 어떤 종류의 코어를 선호할지에 영향을 줍니다.

Windows 11의 대략적인 분류는 다음과 같습니다.

이 표는 Microsoft Learn의 「Quality of Service」에 있는 2개의 표, 즉 QoS 레벨 목록(High / Medium / Low / Utility / Eco / Media / Deadline)과 QoS 분류(윈도우의 표시 상태로 QoS를 정하는 대응)를 다시 정리한 것입니다. 관측에서 일으킨 분류가 아닙니다. 같은 문서에는 소리를 내고 있다고 판정된 프로세스는 High로 취급한다는 규정과, 위의 어느 것에도 해당하지 않는 스레드는 우선도 등의 휴리스틱으로 자동 할당한다는 설명도 있습니다.

하나 더, 측정하는 사람에게 중요한 기술이 있습니다. 배터리 구동 중에 일정 시간 사용자 입력이 없으면 전면 앱의 QoS가 Medium으로 내려갈 수 있다는 기능입니다. 문서에는 배터리로 성능 측정을 할 때는 이 기능을 비활성화해야 한다는 주의사항이 있고, 비활성화 방법으로 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerThrottling의 DisableUserPresenceQos(REG_DWORD)에 1을 설정하는 절차가 안내되어 있습니다. 입력이 없는 자동 테스트에서 「배터리일 때만 느리다」가 나오면 먼저 여기를 의심하는 것이 빠릅니다.

여기서 중요한 것은 최소화한 것만으로 QoS가 바뀔 수 있다는 점입니다. 즉 하이브리드 CPU의 노트북에서는,

• 앱을 전면에서 뺐다
• 게다가 최소화했다
• 그 결과 QoS가 내려갔다
• efficient core 쪽에 놓이기 쉬워졌다
• 체감이나 마감이 악화됐다

라는 일이 평범하게 일어납니다.

flowchart TB
    accTitle: 최소화에서 마감 악화까지의 연쇄
    accDescr: 하이브리드 CPU의 노트북에서는 앱을 전면에서 빼고 최소화하면 QoS가 내려가고, 배터리 시에는 efficient core 쪽에 놓이기 쉬워져 체감이나 마감이 악화되는 연쇄가 평범하게 일어남을 보여주는 그림.
    mn2["전면에서 빼고 최소화"] --> qd1["QoS가 내려간다"]
    qd1 -->|"배터리 시에는 특히"| ec1["efficient core 쪽에 놓인다"]
    ec1 --> ws1["체감이나 마감이 악화"]

그림 14: 최소화라는 조작만으로 코어 배치까지 이어지는 연쇄가 일어날 수 있다.

6.3 Thread Director와 hybrid scheduling

Intel의 12th Gen 이후 hybrid CPU에서는 Intel Thread Director가 OS에 힌트를 냅니다. Windows 11은 이것을 사용해 P 코어 / E 코어의 할당을 더 똑똑하게 정합니다.

덧붙여 Windows 쪽에는 heterogenous scheduling 정책이 있습니다.

• SchedulingPolicy
• ShortSchedulingPolicy
• ShortThreadRuntimeThreshold

이것들은 Automatic으로 두면 QoS와 시스템 구성을 보고 OS가 정하는 구조입니다. 게다가 그 뒤에서는 processor power management 쪽의 core parking engine이나 performance state engine도 동작하고 있습니다.

전체상은 대체로 이렇게 파악하면 이해하기 쉽습니다.

flowchart TD
    t["Thread"] --> p["Priority / dynamic priority"]
    t --> q["QoS (High / Medium / Low / Utility / Eco / Deadline)"]
    t --> v["Visibility / audible / input state"]
    t --> h["Hybrid scheduling policy<br/>SCHEDPOLICY / SHORTSCHEDPOLICY"]
    t --> td["Intel Thread Director hints<br/>Windows 11 on Intel hybrid"]
    v --> q
    p --> s["Windows scheduler + Processor Power Management"]
    q --> s
    h --> s
    td --> s
    s --> c["P 코어 / E 코어와 주파수가 정해진다"]

그림 15: 우선도·QoS·가시 상태·scheduling 정책·Thread Director의 힌트가 합류해 코어와 주파수가 정해진다.

7. 어떤 때 효과가 있고, 어떤 때는 효과가 없는가

실무적으로는 효과가 있기 쉬운 경우와 별개 문제인 경우를 나누어 보는 편이 빠릅니다.

7.1 효과가 있기 쉬운 경우

이럴 때는 백그라운드 서비스가 합리적인 대책이 될 수 있습니다.

• 전면 앱으로 포커스를 옮기면 뒤의 연속 처리만 불안정해진다
• CPU 사용률은 포화되지 않았는데 주기 처리의 마감만 떨어진다
• 크리티컬한 처리가 legacy app / helper process / worker thread 쪽에 있고, MMCSS나 QoS의 사용이 충분하지 않다
• 서비스나 상주 처리가 주역이고, 전면 UI의 쾌적함보다 뒤 처리의 안정이 중요

7.2 효과가 없거나 별개 문제인 경우

반대로 이 설정만으로는 부족한 문제도 있습니다.

• DPC / ISR 지연이 크다
• USB controller나 audio driver의 불량
• USB selective suspend나 디바이스 절전의 영향
• thermal throttling
• battery saver나 power throttling, EcoQoS의 영향
• 버퍼 사이즈가 너무 작다
• 앱이 이미 MMCSS / Deadline을 올바르게 쓰고 있고, 문제가 다른 곳에 있다

특히 Windows 11 + hybrid CPU 노트북에서는 visibility와 QoS의 변화가 꽤 크게 작용합니다. 최소화하면 느려진다, 배터리에서만 나빠진다는 상황이라면 프로세서 스케줄링보다 QoS / power 쪽을 의심하는 편이 맞을 확률이 높습니다.

flowchart TB
    accTitle: 증상으로 어느 쪽을 의심할지 판단하기
    accDescr: 포커스를 옮기면 뒤의 연속 처리만 불안정해진다면 이 설정이 후보가 되고, 최소화나 배터리에서만 악화되면 QoS나 power 쪽, DPC/ISR 지연이나 드라이버 유래라면 별개 문제로 파고든다는 구분을 보여주는 그림.
    smp2["증상이 나타나는 양상을 본다"] -->|"전면으로 옮기면 뒤가 불안정"| this1["이 설정이 후보가 된다"]
    smp2 -->|"최소화·배터리에서만 악화"| qsp1["QoS / power 쪽을 의심한다"]
    smp2 -->|"DPC / ISR·드라이버 유래"| oth2["이 설정으로는 고쳐지지 않는 별개 문제"]

그림 16: 증상의 조건 의존성이 이 설정·QoS·별개 문제 중 어느 것인지를 알려준다.

8. 실무에서의 관점

실제로 구분하려면 순서로는 다음이 이해하기 쉽습니다.

1. 조건을 고정한다
   • AC 급전인가, 배터리인가
   • 전원 모드
   • 버퍼 사이즈
   • foreground / visible / minimized 상태
2. 프로그램과 백그라운드 서비스를 같은 조건에서 비교한다
   • 체감뿐만 아니라 dropout 횟수, glitch 횟수, 처리 지연을 기록한다
3. Windows 11 / hybrid CPU라면 QoS 쪽을 의심한다
   • 최소화에서만 악화되는가
   • audible 상태에서 바뀌는가
   • 배터리에서만 악화되는가
4. 음성이나 영상이라면 MMCSS를 먼저 본다
   • 중요 스레드가 Windows에 「이것은 마감이 중요하다」고 전달되고 있는가
5. 그래도 고쳐지지 않으면 DPC / ISR / USB / driver를 판다
   • 여기는 스케줄러 이전의 이야기가 된다

flowchart TB
    accTitle: 구분의 순서
    accDescr: 먼저 조건을 고정하고, 프로그램과 백그라운드 서비스를 같은 조건에서 비교하고, hybrid CPU라면 QoS 쪽을 의심하고, 음성이나 영상이라면 MMCSS를 확인하고, 그래도 고쳐지지 않으면 DPC/ISR나 드라이버를 파고든다는 구분 순서를 보여주는 그림.
    o1["조건을 고정한다"] --> o2["2가지 설정을 같은 조건에서 비교"]
    o2 --> o3["hybrid CPU라면 QoS 쪽을 의심"]
    o3 --> o4["음성·영상이라면 MMCSS를 확인"]
    o4 --> o5["남으면 DPC / ISR·드라이버를 판다"]

그림 17: 구분은 조건 고정에서 시작하고, 스케줄러 이전의 층은 마지막에 판다.

8.1 각각 무엇을 어떻게 확인하는가

「의심한다」에서 멈추지 않도록 확인 방법을 정리해 둡니다.

wpr은 Windows Performance Recorder의 명령어로, Windows ADK에 포함되어 있습니다. 관리자 권한 콘솔에서 실행합니다.

실무에서는 평균 CPU 사용률보다 「마감에 맞췄는가」가 더 중요합니다. 여기가 꽤 본질입니다.

flowchart TB
    accTitle: 봐야 할 지표는 마감
    accDescr: 이런 종류의 문제에서는 평균 CPU 사용률보다 주기 처리가 마감에 맞았는가가 더 중요한 지표임을 보여주는 그림.
    avg2["평균 CPU 사용률"] -.->|"이것만으로는 부족하다"| judge1["안정성 판단"]
    ddl1["마감에 맞췄는가"] -->|"이쪽을 본다"| judge1
    ddl1 -.-> cnt1["dropout이나 glitch의 횟수로 센다"]

그림 18: 평균이 낮아도 마감은 놓칠 수 있으므로, 맞았는지를 세어 판단한다.

9. 정리

프로세서 스케줄링을 백그라운드 서비스로 바꾸면 무슨 일이 일어나는지를 꽤 짧게 다시 말하면 이렇습니다.

• 바뀌는 것은 CPU의 속도 그 자체가 아니라 foreground와 background 사이의 CPU 시간 배분 방식
• 프로그램은 전면 앱을 쾌적하게 하기 쉽다
• 백그라운드 서비스는 뒤의 연속 처리가 밀리기 어려워진다
• 그래서 음성, 영상, 캡처, 감시, 상주 처리처럼 뒤의 마감이 중요한 경우에는 효과가 있을 수 있다
• 다만 P 코어 / E 코어 CPU에서는 실제의 core 배치가 QoS, power policy, hybrid scheduling, Thread Director 등도 강하게 작용한다
• 그래서 요즘의 Windows에서는 이 설정을 효과가 있을 때는 있지만 단독의 주역은 아니다라고 보는 것이 자연스럽다

요컨대 이것은 CPU의 마력을 올리는 손잡이가 아니라 일의 할당을 바꾸는 손잡이입니다.

전면 앱의 경쾌함을 우선할지, 뒤의 연속 처리의 마감을 지키기 쉽게 할지. 그 균형을 조금 background 쪽으로 기울이는 설정이라고 생각하면 꽤 납득이 갑니다.

그리고 hybrid CPU 시대에는 그 위에 다시 QoS와 P / E 코어 선택의 층이 얹혀 있습니다. 여기까지 포함해서 보면 「왜 효과가 있을 때가 있는가」, 「왜 효과가 없을 때도 있는가」가 보이기 시작합니다.

flowchart TB
    accTitle: 이 손잡이의 현대에서의 위치
    accDescr: 이 설정은 일의 할당을 background 쪽으로 조금 기울이는 손잡이이며, hybrid CPU 시대에는 그 위에 QoS와 P 코어/E 코어 선택의 층이 얹혀 있기 때문에 효과가 있을 때는 있지만 단독의 주역은 아님을 보여주는 그림.
    knob1["할당을 background 쪽으로 기울이는 손잡이"] --> base2["quantum과 우대의 층"]
    base2 -.->|"그 위에 얹힌다"| upper1["QoS와 P / E 코어 선택의 층"]
    upper1 --> view1["효과가 있는 이유도 없는 이유도 보이기 시작한다"]

그림 19: 이 손잡이는 아래층에 작용할 뿐이고, 현대의 코어 선택은 그 위층이 정한다.

10. 참고 자료

• Sawady: バックグラウンドサービスを優先する設定（CPUをサボらせない）
• Microsoft Learn: Win32_OperatingSystem class
• Microsoft Learn: Win32PrioritySeparation 레지스트리 값 설명 - 비트의 의미와 UI 선택이 기록하는 값.
• Microsoft Learn: Master Your Quantum - Win32PrioritySeparation 값별 quantum.
• Microsoft Learn: Know Thy Tick - clock tick과 quantum의 관계.
• Microsoft Learn: CPU Analysis in Windows Performance Analyzer
• Microsoft Learn: Windows Performance Recorder
• Microsoft Learn: Priority Boosts
• Microsoft Learn: Window Features
• Microsoft Learn: Quality of Service
• Microsoft Learn: SetThreadInformation function
• Microsoft Learn: SetProcessInformation function
• Microsoft Learn: Multimedia Class Scheduler Service
• Microsoft Learn: Processor power management options overview
• Microsoft Learn: SchedulingPolicy
• Microsoft Learn: ShortSchedulingPolicy
• Microsoft Learn: ShortThreadRuntimeThreshold
• Intel Support: Is Windows 10 Task Scheduler Optimized for 12th Generation Intel Core Processors?
• Intel White Paper: Intel performance hybrid architecture & software optimizations, Part Two

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

「프로세서 스케줄링」을 「백그라운드 서비스」로 바꾸면 무엇이 바뀌나요?

바뀌는 것은 CPU의 속도나 클럭이 아니라 전면 앱과 배후에서 도는 처리 사이의 CPU 시간 배분 방식입니다. 내부적으로는 Win32PrioritySeparation과 연결된 설정으로, quantum(타임 슬라이스)의 배분 방식과 foreground의 우대 정도에 작용합니다. 「프로그램」은 전면 앱을 우대하기 쉽고, 「백그라운드 서비스」는 전면과 배후를 더 균등하게 다루는 방향입니다. 참고로 이 설정을 골라도 자신의 앱이 Windows 서비스가 되는 것은 아닙니다.

「백그라운드 서비스」로 하면 소리의 지직거림이 고쳐지는 경우가 있는 이유는 무엇인가요?

음성 처리는 평균적으로 빠른 것만으로는 부족하고, 수 밀리초마다의 마감까지 버퍼를 채워야 하기 때문입니다. 「프로그램」 설정에서는 전면 앱 쪽이 길게 달리기 쉬워, 뒤의 음성 처리가 평균으로는 문제없어도 그 순간만 늦어져 underrun이 되는 경우가 있습니다. 「백그라운드 서비스」로 돌리면 뒤의 연속 처리가 CPU를 되찾기 쉬워져 deadline miss가 줄어드는 경우가 있습니다. 다만 DPC/ISR 지연, USB 절전, 드라이버 불량, thermal throttling, EcoQoS에서 비롯된 문제는 이 설정으로는 고쳐지지 않습니다.

「백그라운드 서비스」로 하면 배경 처리가 P 코어에서 동작하게 되나요?

그렇게 되지 않습니다. P 코어와 E 코어 중 어느 쪽에 올라가는가는 이 설정보다 QoS, 전원 정책, hybrid scheduling, Intel Thread Director 같은 것들이 더 강하게 작용합니다. Windows 11에서는 앱을 최소화한 것만으로 QoS가 내려가, 배터리 구동 시에는 efficient core 쪽에 놓이기 쉬워지는 일도 평범하게 일어납니다. 최소화에서만 느려지거나 배터리에서만 나빠지는 경우라면, 이 설정보다 QoS나 power 쪽을 의심하는 편이 맞을 확률이 높습니다.

음이 끊기거나 드롭아웃이 일어나는 원인은 어떻게 구분하면 되나요?

먼저 AC 급전인지, 전원 모드, 버퍼 사이즈, 전면·최소화 상태 같은 조건을 고정하고, 「프로그램」과 「백그라운드 서비스」를 같은 조건에서 비교해 dropout 횟수나 처리 지연을 기록합니다. Windows 11의 hybrid CPU라면 최소화나 배터리에서만 악화되는지를 보고 QoS 쪽을 의심합니다. 음성이나 영상이라면 중요 스레드가 MMCSS를 쓸 수 있는지를 먼저 확인하고, 그래도 고쳐지지 않으면 DPC/ISR·USB·드라이버를 파고듭니다. 여기까지 오면 스케줄러 이전의 이야기가 됩니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.