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

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

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

다만 이 설정은 마법의 고속화 스위치가 아닙니다. CPU의 클럭을 직접 올리는 설정도, 앱을 Windows 서비스로 바꾸는 설정도, P 코어로 고정하는 설정도 아닙니다. 주로 바뀌는 것은 전면 앱과 배후에서 도는 처리 사이에서 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의 주파수 설정이 아니라 줄 서기의 규칙을 바꾸는 설정입니다.

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

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

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

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

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

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

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

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

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

대략 정리하면 차이는 다음과 같이 보면 이해하기 쉽습니다.

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

한편으로 예를 들어 다음과 같은 경우는 이야기가 달라집니다.

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

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

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

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

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

예를 들어 다음과 같은 상황을 생각합니다.

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

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

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

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

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

는 흐름입니다.

5. 원리 - quantum과 foreground의 우대

조금 더 저레이어 쪽으로 보면, 효과의 줄거리는 이렇습니다.

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

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

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

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

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

Windows는 원래 foreground에 꽤 신경 씁니다. 대표적으로는 다음 같은 것들이 있습니다.

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

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

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

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

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

그래서 이 설정은,

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

라는 것이 됩니다.

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가지는 같지 않습니다.

6.2 Windows 11의 QoS와 visibility

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

대충 보면 Windows 11에는 다음과 같은 분류가 있습니다.

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

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

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

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 코어와 주파수가 정해진다"]

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의 노트 PC에서는 visibility와 QoS의 변화가 꽤 효과가 있습니다. 최소화로 느려진다, 배터리에서만 나빠진다라면 프로세서 스케줄링보다 QoS / power 쪽을 의심하는 편이 맞을 확률이 높습니다.

8. 실무에서의 관점

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

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

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

9. 정리

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

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

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

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

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

10. 참고 자료

• Sawady: バックグラウンドサービスを優先する設定（CPUをサボらせない）
• Microsoft Learn: Win32_OperatingSystem class
• 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