Windows 앱 개발자를 위한 CPU 설정 입문: 우선순위·선호도·P코어/E코어

Windows 앱의 성능은 코드만으로 결정되지 않습니다. 같은 .exe라도, 실행하는 PC에 따라 체감이 달라지는 경우가 있습니다.

어떤 PC에서는 주기 처리가 안정적이다.
다른 PC에서는, 가끔 지연된다.
AC 전원에서는 문제없는데, 배터리로 구동하면 유난히 느리다.
작업 관리자에서 우선순위를 올렸는데, 생각만큼 빨라지지 않는다.
P코어로 몰았다고 생각했는데, 여전히 처리 시간이 흔들린다.
반대로, 성능을 올리려다 팬이 멈추지 않고, 다른 앱이 무거워진다.

Windows 앱을 만들다 보면, 이런 “코드만으로는 설명하기 어려운 현상”을 만납니다.

그때 봐야 할 것이 이 네 가지입니다.

게다가 최근 Windows에서는, 여기에 EcoQoS와 작업 관리자의 Efficiency mode도 관련됩니다.

즉, Windows 앱의 실행 환경은 단순히 “CPU가 빠른지 느린지”가 아닙니다.

언제 실행되는가
어디에서 실행되는가
어떤 종류의 코어에서 실행되는가
CPU가 어느 정도의 성능 상태로 동작하는가
OS가 "성능 중시"로 보는지, "절전으로 충분"하다고 보는지

이런 요소가 겹쳐, 실제 응답성과 처리 시간이 결정됩니다.

이 글에서는 Windows 앱 개발에서 놓치기 쉬운 우선순위, 선호도, P코어/E코어, 절전 설정의 관계를 정리합니다.

참고로, 이 글에 나오는 코드는 빌드·실행할 수 있는 샘플 세트(우선순위·선호도를 다루는 C# 라이브러리와 데모, PowerShell 스크립트, 단위 테스트)로 GitHub에 공개하고 있습니다.

windows-app-cpu-priority-affinity-power - komurasoft-blog-samples (GitHub)

1. 먼저 전체 그림

먼저, 전체 그림을 그리면 이렇습니다.

flowchart LR
  A["앱 코드"] --> B["Windows 스케줄러"]

  P["우선순위<br/>언제 실행되기 쉬운가"] --> B
  AF["선호도 / CPU Sets<br/>어느 CPU에서 실행해도 되는가"] --> B
  Q["QoS / EcoQoS<br/>성능 중시인가, 절전 중시인가"] --> B

  B --> C["실행할 스레드를 고른다"]
  C --> D["실행할 논리 프로세서를 고른다"]

  PE["P코어 / E코어<br/>성능 쪽인가, 절전 쪽인가"] --> D
  PM["전원 모드 / 전원 플랜 / PPM<br/>주파수·부스트·Core Parking"] --> D

  D --> R["실제 응답성<br/>처리 시간<br/>발열<br/>배터리 소비<br/>다른 앱에 대한 영향"]

중요한 점은, 이들이 서로 독립적이지 않다는 것입니다.

우선순위를 올리면 실행되기는 쉬워집니다.
하지만 CPU 자체가 절전 쪽으로 제어되고 있으면, 기대한 만큼 빨라지지 않는 경우가 있습니다.

선호도로 CPU를 좁히면 스레드 이동은 줄어들 수 있습니다.
하지만 좁힌 대상이 절전 쪽 코어이거나, Core Parking·전원 관리와 어긋나면, 오히려 불리해질 수 있습니다.

P코어로 몰면 계산은 빨라질 수 있습니다.
하지만 모든 것을 고성능 쪽으로 몰면 발열, 팬 소음, 배터리 소비, 다른 프로세스에 대한 영향이 늘어납니다.

Windows 앱의 성능 조정은, 단순한 “빠르게 만드는 버튼 찾기”가 아닙니다.

어느 처리를 빠르게 하고 싶은가.
어느 처리는 느려도 되는가.
사용자 조작의 응답성을 우선할 것인가.
백그라운드 처리의 완료 시간을 우선할 것인가.
배터리나 발열을 어디까지 허용할 것인가.

결국 설계의 문제입니다.

이 글의 지식 맵

Windows 앱의 실행 환경은 Windows 스케줄러가 어떤 스레드를 실행할지 정하는 CPU 우선순위, 실행해도 되는 CPU 범위를 정하는 선호도, 성능 중시인지 절전 중시인지를 나타내는 QoS로 구성됩니다. 우선순위는 I/O 대기나 락 경합처럼 CPU 밖의 병목에는 효과가 없고, 일상적으로 높이면 다른 스레드의 응답성이 나빠질 수 있습니다. 실행되는 논리 프로세서의 성격은 P코어·E코어에서 다르며, CPU 번호를 고정하지 말고 CPU Sets의 EfficiencyClass로 구분해야 합니다. 전원 모드는 P-state·C-state·EPP·Core Parking을 통해 CPU 주파수를 좌우하며, 절전 쪽 설정은 우선순위나 P코어 배치만으로는 메울 수 없는 주기 흔들림을 만듭니다. EcoQoS와 작업 관리자의 Efficiency mode는 우선순위 하락과 EcoQoS의 조합으로, 급하지 않은 백그라운드 처리를 포그라운드 앱을 방해하지 않는 형태로 실행시키는 메커니즘입니다.

flowchart LR
    accTitle: Windows 앱의 CPU 우선순위·선호도·전원 설정의 지식 맵
    accDescr: Windows 스케줄러의 실행 순서가 CPU 우선순위·선호도·QoS로 구성되고, 실행할 코어 선택에 P코어/E코어와 Core Parking을 포함한 전원 모드가 관여하며, EcoQoS와 작업 관리자의 Efficiency mode가 백그라운드 처리를 절전 쪽으로 넘기는 메커니즘임을 보여주는 그림
    cpu_scheduling_priority["CPU 우선순위(스케줄링 우선순위)"]
    cpu_affinity["CPU 선호도"]
    heterogeneous_cpu_cores["P코어/E코어 혼재 CPU"]
    windows_scheduler["Windows 스케줄러"]
    qos["QoS(Quality of Service)"]
    non_cpu_bottleneck["CPU 외의 병목 요인"]
    system_responsiveness_degradation["시스템 전반의 응답성 악화"]
    realtime_sensitive_processing["실시간성이 요구되는 처리"]
    etw["ETW(Event Tracing for Windows)"]
    core_parking["Core Parking"]
    p_core["P코어"]
    e_core["E-코어"]
    cpu_sets["CPU Sets"]
    efficiency_class["EfficiencyClass(CPU Sets 효율 특성값)"]
    wpr_wpa["WPR/WPA(Windows Performance Recorder/Analyzer)"]
    power_mode["전원 모드/전원 관리 옵션(PPM)"]
    p_state["P-state"]
    c_state["C-state"]
    epp["EPP(Energy Performance Preference)"]
    reduced_cpu_frequency["CPU 주파수 저하"]
    periodic_timing_jitter["주기 처리 지터"]
    ecoqos["EcoQoS"]
    background_maintenance_task["급하지 않은 백그라운드 처리"]
    task_manager_efficiency_mode["작업 관리자의 Efficiency mode"]
    windows_scheduler -->|"에서 구성할 수 있다"| cpu_scheduling_priority
    windows_scheduler -->|"에서 구성할 수 있다"| cpu_affinity
    windows_scheduler -.->|"에서 구성할 수 있다"| qos
    cpu_scheduling_priority -->|"사용은 비권장"| non_cpu_bottleneck
    cpu_scheduling_priority -.->|"원인이 될 수 있다"| system_responsiveness_degradation
    cpu_scheduling_priority -.->|"권장되는 대응"| realtime_sensitive_processing
    non_cpu_bottleneck -->|"에서 확인할 수 있다"| etw
    cpu_affinity -.->|"양립하지 않는다"| core_parking
    cpu_affinity -.->|"권장되는 대응"| p_core
    cpu_affinity -.->|"사용은 비권장"| e_core
    cpu_sets -->|"이용한다"| efficiency_class
    p_core -->|"에서 확인할 수 있다"| efficiency_class
    e_core -->|"에서 확인할 수 있다"| efficiency_class
    windows_scheduler -->|"에서 확인할 수 있다"| wpr_wpa
    power_mode -->|"이용한다"| p_state
    power_mode -->|"이용한다"| c_state
    power_mode -->|"이용한다"| epp
    power_mode -->|"이용한다"| core_parking
    power_mode -.->|"원인이 될 수 있다"| reduced_cpu_frequency
    reduced_cpu_frequency -.->|"원인이 될 수 있다"| periodic_timing_jitter
    ecoqos -->|"이용한다"| qos
    ecoqos -->|"권장되는 대응"| background_maintenance_task
    ecoqos -->|"사용은 비권장"| realtime_sensitive_processing
    task_manager_efficiency_mode -->|"이용한다"| ecoqos
    task_manager_efficiency_mode -->|"이용한다"| cpu_scheduling_priority

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

2. 우선순위는 “언제 실행되기 쉬운가”

Windows에서는 실행 가능한 스레드가 여러 개 있을 때, 스케줄러가 “다음에 어느 스레드를 CPU에 올릴지”를 정합니다. 이때 작용하는 것이 우선순위입니다.

우선순위는 크게 보면 2단계로 결정됩니다.

프로세스의 우선순위 클래스
  + 스레드의 상대 우선순위
  = 스레드의 기본 우선순위

Win32 API로 말하면, 프로세스 쪽에는 SetPriorityClass, 스레드 쪽에는 SetThreadPriority가 있습니다.

PowerShell로 지금 실행 중인 프로세스의 우선순위를 보려면, 예를 들면 이렇습니다.

Get-Process -Id $PID | Select-Object Id, ProcessName, PriorityClass

현재 PowerShell 프로세스의 우선순위를 올리려면, 이렇게 합니다.

$p = Get-Process -Id $PID
$p.PriorityClass = "AboveNormal"

C#이라면 다음과 같이 작성합니다.

using System.Diagnostics;

using var process = Process.GetCurrentProcess();
process.PriorityClass = ProcessPriorityClass.AboveNormal;

여기서 주의할 점은, 우선순위가 “CPU를 빠르게 만드는 설정”이 아니라는 것입니다. 우선순위가 관여하는 것은, 경쟁이 있을 때 어느 스레드를 먼저 실행할지입니다.

CPU 주파수를 올리는 설정이 아닙니다.
P코어를 고르는 설정도 아닙니다.
I/O를 빠르게 하는 설정도 아닙니다.
잠금 대기나 네트워크 대기를 없애는 설정도 아닙니다.

그래서 “우선순위를 올렸는데 빨라지지 않는다”는 흔히 있는 일입니다. 예를 들어 느린 원인이 다음과 같다면, 우선순위를 올려도 본질적으로는 해결되지 않습니다.

• 디스크 I/O 대기
• 네트워크 대기
• DB 응답 대기
• 잠금 경쟁
• GC 정지
• UI 스레드 차단
• GPU나 드라이버 쪽 대기
• 백신 소프트웨어의 파일 스캔
• CPU 주파수가 절전 쪽으로 억제되어 있음

또한 HIGH_PRIORITY_CLASS나 REALTIME_PRIORITY_CLASS는 함부로 쓰는 것이 아닙니다.

높은 우선순위로 오래 계속 실행되는 스레드는, 다른 스레드에 CPU 시간을 넘기기 어려워집니다.
그것이 자기 앱 안에서만이라면 그렇다 쳐도, 시스템 전체의 응답성을 나쁘게 만드는 경우가 있습니다.

우선순위는 약과 같습니다.

효과가 있는 상황에서는 효과가 있습니다.
하지만 양을 늘리면 좋아지는 것은 아닙니다.

우선순위를 올리기 전에 생각할 것

우선순위를 올리기 전에, 먼저 생각할 점이 있습니다.

Windows 앱에서 중요한 것은, 항상 최고 우선순위로 실행하는 것이 아니라, 필요한 처리를 필요한 시점에 필요한 범위만 우선하는 것입니다.

3. 선호도는 “어느 CPU에서 실행해도 되는가”

우선순위가 “언제 실행되기 쉬운가”라면, 선호도는 “어느 CPU에서 실행해도 되는가”입니다.

Windows에서는 프로세스나 스레드에 대해, 실행 가능한 논리 프로세서의 집합을 지정할 수 있습니다.

Win32 API에서는 프로세스에 SetProcessAffinityMask, 스레드에 SetThreadAffinityMask가 있습니다.

PowerShell로 프로세스의 선호도를 보려면, 예를 들면 이렇습니다.

Get-Process -Id $PID | Select-Object Id, ProcessName, ProcessorAffinity

검증 목적으로, 현재 PowerShell 프로세스를 처음 4개의 논리 프로세서로 좁히려면 이렇게 작성합니다.

$p = Get-Process -Id $PID
$p.ProcessorAffinity = [IntPtr]0xF

0xF는 2진수로 1111입니다.
즉, 논리 프로세서 0~3을 허용한다는 뜻입니다.

다만 이는 검증용 예에 지나지 않습니다.

선호도를 좁히면 CPU 캐시 지역성이 좋아지거나, 주기 처리의 흔들림이 줄어드는 경우가 있습니다.
한편 Windows가 원래 비어 있는 CPU로 옮길 수 있었을 스레드를, 좁은 곳에 가두는 일이 되기도 합니다.

특히 이런 환경에서는 주의가 필요합니다.

• P코어/E코어가 섞여 있다
• SMT/Hyper-Threading(Simultaneous Multi-Threading. 하나의 물리 코어를 여러 논리 프로세서로 보이게 하는 구조) 때문에, 논리 프로세서와 물리 코어의 대응이 직관적이지 않다
• NUMA(Non-Uniform Memory Access. CPU에서 본 메모리까지의 거리가 균일하지 않은 구성)이다
• 논리 프로세서가 64개를 넘어 Processor Group이 관련된다
• Core Parking이 켜져 있다
• OEM이나 BIOS의 전원 제어가 강하다
• 가상 환경에서 실행 중이다

선호도는 시스템에 “이 CPU에서만 실행하라”고 강하게 제약을 거는 설정입니다.

제약은 안정화의 도구가 되기도 합니다.
하지만 잘못하면 빠져나갈 길을 막습니다.

지금은 CPU Sets도 있다

고전적인 선호도 마스크는 꽤 강한 제약입니다.

한편 Windows에는 CPU Sets라는 구조도 있습니다.
CPU Sets는 애플리케이션 쪽이 CPU에 대한 희망을 더 부드럽게 전달하기 위한 API입니다.

Microsoft의 설명에서는, CPU Sets는 OS 전원 관리와 호환되는 “soft” affinity로 다룹니다.

CPU를 엄격히 고정하고 싶은가.
OS의 전원 관리나 스케줄링과 맞추면서, 대략의 실행 위치를 모으고 싶은가.

이 차이는 중요합니다.

예전 방식의 SetProcessAffinityMask로 모두 해결하려 하지 말고, 최근 Windows 앱에서는 CPU Sets나 QoS까지 포함해 생각할 필요가 있습니다.

4. P코어/E코어는 “CPU에도 성격이 있다”는 이야기

최근 CPU에서는 모든 코어가 같은 성능·같은 소비 전력이라고 할 수 없습니다. 대표적인 것이 P코어와 E코어이며, 대략 말하면 P코어는 성능 쪽, E코어는 효율 쪽 코어입니다.

다만 개발자가 함부로 “CPU 0~7이 P코어이고, 8~15가 E코어”라고 번호를 고정해 가정하는 것은 위험합니다. CPU 번호 배치는 CPU, BIOS, Windows 버전, 펌웨어, OEM 설정, 가상화 환경에 따라 달라질 수 있습니다.

Windows 쪽에서는 CPU Sets 정보에 EfficiencyClass라는 개념이 있습니다.
이는 이종 프로세서를 가진 시스템에서, 그 CPU Set의 효율 특성을 나타내는 값입니다. Microsoft 문서에서는, 이 값이 높은 CPU Set일수록 더 빠르지만 전력 효율은 낮은 프로세서를 가진다고 설명합니다.

P코어/E코어를 다루려면 CPU 번호만 봐서는 부족합니다. 제대로 파고들려면 이런 관찰이 필요합니다.

• CPU Sets API로 EfficiencyClass를 본다
• Windows Performance Recorder / Analyzer(WPR / WPA. ETW 추적을 수집해 분석하는 표준 도구)로 스레드의 실행 CPU를 본다
• 작업 관리자의 논리 프로세서 표시로 경향을 본다
• 실제 기기마다 처리 시간을 잰다
• AC 전원 시와 배터리 시를 비교한다
• 전원 모드를 바꿔 비교한다

P코어/E코어는 단순한 하드웨어 사양이 아니라, Windows 스케줄러, QoS, 절전 설정과 겹쳐 실제 실행 위치가 정해집니다.

5. 절전 설정은 “CPU를 얼마나 본격적으로 돌릴지”에 관련된다

이곳이 현장에서는 꽤 중요합니다.

우선순위는 “어느 스레드를 먼저 실행할지”.
선호도는 “어느 CPU에서 실행해도 되는지”.
P코어/E코어는 “그 CPU가 성능 쪽인지, 절전 쪽인지”.

그리고 절전 설정은,

애초에 CPU를 어느 정도의 주파수·전력 상태로 동작시킬지

에 관련됩니다.

즉 이런 일이 일어납니다.

우선순위를 올렸다.
P코어로 몰았다.
그런데 전원 설정이 절전 쪽이라면,
CPU는 본격적으로 돌지 않을 수 있다.

이는 Windows에서 꽤 흔히 있는 이야기입니다.

Windows 11에서는 설정 앱의 “시스템 > 전원 및 배터리”에서 전원 모드를 고를 수 있습니다.
표기는 환경이나 버전에 따라 달라지지만, 방향은 대략 이렇습니다.

추가로 예전부터 있는 전원 플랜에는 Power Saver, Balanced, High Performance가 있습니다.
Balanced는 수요에 따라 성능과 소비 전력을 조정하고, High Performance는 소비 전력을 대가로 최대 성능을 내기 쉬운 방향의 설정입니다.

사용자에게 보이는 설정은 단순해도, 뒤에는 Processor Power Management, PPM, 설정이 있습니다.

6. P-state, C-state, 부스트, EPP

CPU는 항상 최대 주파수로 동작하는 것이 아니라, 소비 전력을 낮추기 위한 상태를 갖습니다.

P-state는 CPU의 주파수나 전압을 바꿔 소비 전력을 낮추는 구조입니다.
C-state는 CPU가 유휴일 때 일부 기능을 멈추고, 더 깊은 절전 상태로 들어가는 구조입니다.

Windows의 전원 관리는 이런 구조를 써서 성능과 소비 전력의 균형을 맞춥니다.

그래서 “높은 우선순위인데 느리다”는 현상은 있을 수 있습니다.

스레드는 우선적으로 실행되고 있다.
하지만 CPU 주파수가 낮다.
부스트에 들어가기 어렵다.
EPP가 절전 쪽이다.
Core Parking으로 쓸 수 있는 코어가 제한되어 있다.
배터리 구동으로 OS 전체가 절전 쪽으로 동작하고 있다.

이런 경우 우선순위만 봐서는 원인에 도달하지 못합니다.

특히 주기 처리, 이미지 처리, 측정기 제어, 동영상 처리, 음성 처리, USB 카메라 캡처, 시리얼 통신 등에서는, 평균 처리 시간뿐 아니라 “가끔 지연되는” 것이 문제가 됩니다.

평균은 빠르다.
하지만 1000번에 한 번만 지연된다.
그 한 번에 버퍼가 막힌다.
UI가 멈춘다.
장치와의 타이밍이 어긋난다.

이런 현상에서는 CPU 사용률 평균만으로는 부족합니다.

처리 시간 분포, 최댓값, 이상치, 전원 상태, 실행 CPU, 백그라운드 부하를 함께 봐야 합니다.

7. Core Parking은 “쓸 수 있는 코어 수”에 관련된다

Windows에는 Core Parking이라는 구조가 있습니다. 쓰지 않는 논리 프로세서를 쉬게 하는 방향의 제어입니다.
사용률이 낮을 때 일부 코어를 저전력 상태로 몰아 소비 전력을 낮춥니다.

Microsoft 자료에서는, CPMinCores를 임의의 시점에 논리 프로세서의 최소 몇 %를 un-parked, 즉 사용 가능 상태로 둘지를 지정하는 설정으로 설명합니다.
값을 100%로 하면 Core Parking 알고리즘은 비활성화됩니다.

여기서 문제가 되는 것이 선호도와의 조합입니다.

선호도로 “이 CPU 그룹에서 실행해 달라”고 제한했다.
하지만 전원 관리상, 그 부근 코어가 어떻게 다루어지는지는 별문제입니다.

Windows Server용 자료에서도, 활성 스레드가 NUMA 노드 안의 CPU 일부에 강하게 선호도가 지정되어 있으면, Core Parking 판단과 어긋나는 경우가 있다고 설명합니다.

이는 클라이언트 PC에서도 참고할 만합니다.

선호도는 스케줄러에 제약을 겁니다.
Core Parking은 전원 관리가 “어느 코어를 사용 가능 상태로 둘지”에 관련됩니다.

이 둘을 따로 생각하면 원인을 잘못 봅니다.

8. EcoQoS / Efficiency Mode는 “이 처리는 절전으로 충분하다”고 알리는 구조

예전에는 Windows 앱의 성능 조정이라고 하면, 우선순위를 올리거나 내리거나, 선호도를 바꾸는 이야기가 중심이었습니다. 하지만 최근 Windows에는 조금 다른 관점이 있습니다. 그것이 QoS입니다.

QoS, Quality of Service는, 스레드에 대해 “이 처리가 얼마나 성능 중시인지, 얼마나 절전 중시인지”를 나타내는 관점입니다.

Microsoft 문서에서는, 스케줄링 우선순위는 다음에 어느 스레드를 실행할지 정하는 주요 지표로 남는 한편, QoS는 코어 선택이나 프로세서 전원 관리에 영향을 줄 수 있다고 설명합니다.

특히 EcoQoS는, 성능이 최우선이 아닌 처리를 절전 쪽으로 다루기 위한 구조입니다.

C++에서는 예를 들어 SetThreadInformation과 ThreadPowerThrottling을 써서, 현재 스레드를 EcoQoS로 만들 수 있습니다.

#include <windows.h>

void EnableEcoQoSForCurrentThread()
{
    THREAD_POWER_THROTTLING_STATE powerThrottling = {};
    powerThrottling.Version = THREAD_POWER_THROTTLING_CURRENT_VERSION;
    powerThrottling.ControlMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED;
    powerThrottling.StateMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED;

    SetThreadInformation(
        GetCurrentThread(),
        ThreadPowerThrottling,
        &powerThrottling,
        sizeof(powerThrottling));
}

반대로 성능 중시로 되돌릴 때는, 같은 제어 대상에 대해 StateMask를 0으로 둡니다.

void DisableEcoQoSForCurrentThread()
{
    THREAD_POWER_THROTTLING_STATE powerThrottling = {};
    powerThrottling.Version = THREAD_POWER_THROTTLING_CURRENT_VERSION;
    powerThrottling.ControlMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED;
    powerThrottling.StateMask = 0;

    SetThreadInformation(
        GetCurrentThread(),
        ThreadPowerThrottling,
        &powerThrottling,
        sizeof(powerThrottling));
}

C#에서 쓸 경우, .NET 클래스 라이브러리에는 EcoQoS를 설정하는 전용 타입이 없습니다. SetThreadInformation을 P/Invoke로 호출합니다. 다음은 .NET 8을 전제로 한 작성법입니다.

using System;
using System.ComponentModel;
using System.Runtime.InteropServices;

internal static class EcoQos
{
    // THREAD_INFORMATION_CLASS 의 ThreadPowerThrottling
    private const int ThreadPowerThrottling = 3;

    // THREAD_POWER_THROTTLING_CURRENT_VERSION
    private const uint CurrentVersion = 1;

    // THREAD_POWER_THROTTLING_EXECUTION_SPEED
    private const uint ExecutionSpeed = 0x1;

    [StructLayout(LayoutKind.Sequential)]
    private struct ThreadPowerThrottlingState
    {
        public uint Version;
        public uint ControlMask;
        public uint StateMask;
    }

    [DllImport("kernel32.dll", SetLastError = true)]
    private static extern IntPtr GetCurrentThread();

    [DllImport("kernel32.dll", SetLastError = true)]
    [return: MarshalAs(UnmanagedType.Bool)]
    private static extern bool SetThreadInformation(
        IntPtr hThread,
        int threadInformationClass,
        ref ThreadPowerThrottlingState threadInformation,
        uint threadInformationSize);

    /// <summary>지금 스레드를 EcoQoS로 둔다(false면 성능 중시로 되돌린다).</summary>
    public static void SetForCurrentThread(bool enabled)
    {
        var state = new ThreadPowerThrottlingState
        {
            Version = CurrentVersion,
            ControlMask = ExecutionSpeed,
            StateMask = enabled ? ExecutionSpeed : 0u,
        };

        var ok = SetThreadInformation(
            GetCurrentThread(),
            ThreadPowerThrottling,
            ref state,
            (uint)Marshal.SizeOf<ThreadPowerThrottlingState>());

        if (!ok)
        {
            throw new Win32Exception(Marshal.GetLastWin32Error());
        }
    }
}

호출 쪽은 다음과 같습니다. EcoQoS는 스레드 단위 설정이므로, 전용 스레드를 만들고 그 안에서 붙였다가 떼는 편이 안전합니다.

using System.Threading;

// RunBackgroundMaintenance 는 직접 준비하는 "급하지 않은 처리"입니다
var worker = new Thread(() =>
{
    EcoQos.SetForCurrentThread(true);
    try
    {
        RunBackgroundMaintenance();
    }
    finally
    {
        // 다 쓰면 반드시 되돌린다
        EcoQos.SetForCurrentThread(false);
    }
})
{
    IsBackground = true,
};

worker.Start();

여기서 주의할 점은, Task.Run이나 스레드 풀 스레드에 직접 붙이지 말라는 것입니다. 설정 대상은 OS 스레드이지, 실행 중인 Task가 아닙니다. 풀의 스레드에 EcoQoS를 붙이면, 그 스레드가 다음에 다른 일로 돌아갈 때도 절전 쪽으로 남습니다. async / await로 continuation이 다른 스레드로 옮겨지면, 의도한 구간 밖에서 걸리거나 안 걸리기도 합니다.

EcoQoS는 무엇이든 절전으로 만들면 되는 기능이 아닙니다. 맞는 것은 예를 들어 이런 처리입니다.

• 백그라운드 동기화
• 낮은 우선순위의 인덱스 작성
• 급하지 않은 로그 집계
• 사용자 조작에 직접 관련되지 않는 캐시 갱신
• 나중에 끝나도 되는 유지보수 처리

반면 이런 처리에는 신중해야 합니다.

• UI 조작에 직결되는 처리
• 카메라 캡처
• 음성 처리
• 제어 주기에 관련된 처리
• 검사 장치의 판정 처리
• 사용자가 기다리고 있는 내보내기 처리
• 실시간성에 가까운 응답이 필요한 처리

작업 관리자의 Efficiency mode도 이 관점과 관련됩니다.
Microsoft의 Performance Diagnostics 블로그에서는, Efficiency mode를 켜면 프로세스의 기본 우선순위를 Low로 낮추고, QoS를 EcoQoS로 설정한다고 설명합니다.

즉 Efficiency mode는 단순한 “절전 아이콘”이 아니라, 낮은 우선순위화와 EcoQoS를 조합해 포그라운드 앱의 응답성과 전력 효율을 지키기 위한 구조입니다.

개발자 관점에서는 이것이 꽤 중요합니다.

“이 처리는 빨리 끝났으면 한다”만이 아니라,
“이 처리는 사용자를 방해하지 않는 범위에서 동작하면 된다”
고 OS에 알리는 설계를 할 수 있기 때문입니다.

9. 판단 흐름도

여기까지의 이야기가 복잡하므로, Windows 앱의 성능이나 주기의 흔들림을 조사할 때의 판단 흐름을 둡니다.

flowchart TD
  A["증상<br/>느리다·주기가 흔들린다·UI가 멈춘다·팬이 시끄럽다"] --> B["먼저 기록한다<br/>처리 시간 / 최댓값 / CPU 사용률 / 전원 상태 / AC or 배터리 / 대상 PC"]
  B --> C{"CPU가 주원인인가?"}

  C -- "아니요 / 불명" --> D["I/O·잠금·DB·네트워크·GC·GPU·드라이버를 확인<br/>우선순위나 선호도보다 먼저 대기 시간을 없앤다"]
  C -- "예" --> E{"다른 프로세스와의 CPU 경쟁이 강한가?"}

  E -- "예" --> F["우선순위를 검토<br/>다만 범위를 한정한다<br/>High/Realtime의 상시 사용은 피한다"]
  E -- "아니요" --> G{"특정 CPU에 치우쳐 있는가?"}

  G -- "예" --> H["선호도 / CPU Sets를 확인<br/>너무 고정하지 않았는가<br/>P/E코어나 NUMA를 보고 있는가"]
  G -- "아니요" --> I{"주파수·전원 상태가 수상한가?"}

  I -- "예" --> J["전원 모드 / 전원 플랜 / PPM을 확인<br/>P-state / EPP / 부스트 / Core Parking을 의심한다"]
  I -- "아니요" --> K{"백그라운드 처리가 포그라운드를 방해하는가?"}

  K -- "예" --> L["EcoQoS / Efficiency Mode / 낮은 우선순위화를 검토<br/>급하지 않은 처리를 절전 쪽으로 넘긴다"]
  K -- "아니요" --> M["알고리즘·병렬도·큐 설계·UI 스레드 설계를 다시 본다"]

  F --> N["한 항목씩 바꿔 A/B 측정"]
  H --> N
  J --> N
  L --> N
  M --> N

  N --> O["평균만이 아니라<br/>최댓값·이상치·발열·다른 앱에 대한 영향을 본다"]

이 흐름에서 중요한 것은, 처음부터 설정을 만지지 않는 것입니다. 먼저 기록합니다.

• 느린 것이 상시인가
• 가끔 느린가
• AC 전원인가 배터리인가
• 전원 모드는 무엇인가
• 작업 관리자에서 Efficiency mode가 아닌가
• CPU 사용률은 높은가
• 주파수는 올라가 있는가
• 어느 스레드가 CPU를 쓰는가
• 처리 시간의 최댓값은 어느 정도인가
• 다른 상주 소프트웨어나 백신 소프트웨어가 관련되어 있지 않은가

그다음에 하나씩 바꿉니다.

우선순위를 바꾼다.
선호도를 바꾼다.
전원 모드를 바꾼다.
EcoQoS를 붙인다.
백그라운드 처리를 분리한다.
큐를 넣는다.
UI 스레드에서 뺀다.

여러 개를 동시에 바꾸면, 무엇이 효과가 있었는지 알 수 없어집니다.

10. 현장에서 확인하는 명령

Windows 앱의 동작이 환경에 따라 다를 때, 우선 상태를 남길 수 있게 해 두면 편합니다.

CPU 정보를 본다

Get-CimInstance Win32_Processor |
  Select-Object Name, NumberOfCores, NumberOfLogicalProcessors, MaxClockSpeed

활성 전원 플랜을 본다

powercfg /getactivescheme

프로세서 전원 관리 설정을 본다

powercfg /q SCHEME_CURRENT SUB_PROCESSOR

출력은 꽤 길지만, 최소·최대 프로세서 상태, EPP, 부스트, Core Parking에 관련된 설정을 확인할 수 있습니다.
환경에 따라 보이는 항목은 다릅니다.

전원 효율 진단 보고서를 만든다

관리자 권한 터미널에서 실행합니다.

powercfg /energy

일정 시간 측정 후 HTML 보고서가 출력됩니다.
드라이버, 장치, 타이머 해상도, USB 절전, 슬립을 방해하는 요인 등을 보는 입구가 됩니다.

대상 프로세스의 우선순위와 선호도를 본다

Get-Process -Name MyApp |
  Select-Object Id, ProcessName, PriorityClass, ProcessorAffinity

작업 관리자에서 확인한다

고객 쪽 단말에서는 PowerShell을 열지 못하는 경우도 있습니다. GUI만으로 확인하고 싶을 때는 다음 위치를 봅니다. 표기는 Windows 버전에 따라 달라지므로, 괄호 안의 영어 이름도 함께 적습니다.

효율 모드는 Windows의 핵심 프로세스에는 적용할 수 없습니다. 멈추면 시스템 안정성에 관련되기 때문입니다.

또한 효율 모드는 표시상의 레이블이 아닙니다. Microsoft의 Performance Diagnostics 블로그에서는, 효율 모드가 프로세스의 기본 우선순위를 Low로 낮추고, QoS를 EcoQoS로 설정한다고 설명합니다. 즉 8장에서 쓴 두 설정을 GUI에서 한 번에 거는 것뿐입니다.

참고로, 작업 관리자의 “세부 정보” 페이지에서 보이는 것은 어디까지나 프로세스 단위 우선순위입니다. 스레드 단위의 상대 우선순위나 스레드마다의 QoS는 표시되지 않습니다. 거기까지 보려면 WPR / WPA로 ETW를 수집합니다.

CPU의 성능 상태를 본다

환경에 따라 쓸 수 있는 카운터 이름은 달라지지만, 이 부근의 Performance Counter가 참고가 됩니다.

Get-Counter '\Processor Information(_Total)\% Processor Performance'

Get-Counter '\Processor Information(_Total)\% Processor Utility'

본격적으로 보려면 Windows Performance Recorder(WPR)와 Windows Performance Analyzer(WPA)로 ETW를 수집하는 편이 확실합니다.
주기의 흔들림, 컨텍스트 스위치, 실행 CPU, DPC/ISR(Deferred Procedure Call / Interrupt Service Routine. 드라이버의 인터럽트 처리와, 그 뒤로 미룬 실행), 디스크 I/O, CPU 주파수 변화를 한꺼번에 따라갈 수 있습니다.

11. 소프트 실시간 처리에서는, 전부 함께 생각한다

Windows는 일반적인 의미의 실시간 OS가 아닙니다. 하지만 현장의 Windows 앱에서는 실시간에 가까운 성질이 요구되는 경우가 있습니다.

• USB 카메라에서 일정 주기로 이미지를 가져온다
• 시리얼 통신으로 장치와 주고받는다
• 측정기에서 데이터를 읽는다
• PLC나 외부 기기와 동기한다
• 음성이나 동영상을 처리한다
• 검사 결과를 일정 시간 안에 돌려준다
• UI를 멈추지 않고 무거운 계산을 돌린다

이런 처리에서는 코드의 속도만으로는 부족합니다.

스레드 설계가 필요합니다.
큐 설계가 필요합니다.
로그가 필요합니다.
타임아웃이 필요합니다.
backpressure(하류가 처리를 따라가지 못할 때, 상류의 유량을 의도적으로 낮추는 구조)가 필요합니다.
지연됐을 때 버릴지, 기다릴지, 재시도할지를 정할 필요가 있습니다.

그리고 그 위에서 우선순위, 선호도, P코어/E코어, 절전 설정을 봐야 합니다.

예를 들어 카메라 캡처 스레드를 생각합니다.

이 스레드는 사용자 조작에 가깝고, 주기성도 있습니다.
그래서 EcoQoS는 붙여서는 안 됩니다.
우선순위는 캡처 구간에 한해 한 단계만 올릴 가치가 있습니다. 다만 HIGH_PRIORITY_CLASS 이상을 상시 사용해서는 안 됩니다. UI나 다른 처리에 악영향이 납니다.
선호도는 실측으로 주기의 흔들림과 CPU 이동의 상관이 보였을 때만 고정합니다. 고정한다면 CPU 번호가 아니라 EfficiencyClass를 보고 P코어 쪽을 골라야 합니다. E코어 쪽으로 고정하면 역효과가 됩니다.
전원 모드가 절전 쪽이면, AC 전원에서는 나오지 않던 지연이 배터리 시에 나옵니다. 그래서 성능 시험에는 배터리 조건을 반드시 넣어야 합니다.

한편 오래된 로그의 압축 처리라면 어떨까요.

이는 사용자가 기다리지 않는 처리의 대표입니다.
그렇다면 우선순위를 낮춘다.
EcoQoS로 둔다.
유휴 시에 돌린다.
AC 전원 시에만 돌린다.
이런 설계가 앱 전체에는 더 낫습니다.

모든 처리를 “빠르게” 하는 것이 아니라, 빠르게 해야 할 처리와 방해하지 말아야 할 처리를 나눕니다.

12. 설계의 기본 방침

Windows 앱에서 이 부근을 다룰 때의 기본 방침은 6가지입니다.

1. 처음부터 고정하지 않는다

처음부터 우선순위나 선호도를 강하게 고정하지 않는 편이 좋습니다.

Windows 스케줄러는 많은 경우 꽤 잘 해 줍니다.
앱 쪽이 불필요한 제약을 걸어서 오히려 나빠지는 경우가 있습니다.

우선 평범하게 만든다.
잰다.
문제가 나오면 가설을 세운다.
작게 바꾼다.
다시 잰다.

이 순서입니다.

2. 우선순위는 일시적으로 쓴다

높은 우선순위는 필요한 구간에만 둡니다.

계속 높은 우선순위로 두기보다,

중요한 처리 직전에 올린다
끝나면 되돌린다

가 더 안전합니다.

3. 선호도는 뒤쪽에서 검토한다

선호도는 강한 설정입니다.

주기의 흔들림이나 CPU 이동의 영향이 의심될 때는 유효한 경우가 있습니다.
하지만 처음에 손대는 설정은 아닙니다.

특히 고객 PC가 여러 종류라면, CPU 번호를 고정해 쓰는 것은 위험합니다.

4. P코어/E코어는 “고정”이 아니라 “관찰”한다

P코어/E코어를 나눠 쓰고 싶다면, 먼저 실제 기기에서 관찰합니다.

CPU 번호로 고정하지 말고, CPU Sets, EfficiencyClass, ETW, 실측으로 봅니다.

5. 절전 설정을 전제로 테스트한다

개발 PC가 AC 전원·고성능 설정이라서 빠르다는 것만으로는 부족합니다.

고객 환경에서는 이런 상태가 흔합니다.

• 노트북의 배터리 구동
• Best power efficiency
• Energy saver
• OEM 고유의 절전 유틸리티
• 기업 정책으로 고정된 전원 설정
• 열로 성능이 떨어지는 슬림 PC
• 상주 소프트웨어가 많은 업무 단말

성능 시험에서는 적어도 이 정도의 조건은 나눠 보고 싶습니다.

6. 백그라운드 처리에는 EcoQoS를 검토한다

사용자 경험에 직결되지 않는 처리는, 성능을 가져가기보다 방해하지 않는 쪽을 우선하는 편이 나은 경우가 있습니다.

모든 것을 고성능으로 돌리는 앱은 빠를지 모릅니다.
하지만 다른 작업을 방해합니다.
노트북 팬을 돌립니다.
배터리를 소비합니다.
결과적으로 쓰기 어려운 앱이 됩니다.

Windows 앱에서는 속도뿐 아니라 “공존을 잘하는 것”도 품질입니다.

13. 흔히 있는 오해

우선순위를 올리면 빨라진다

반드시 빨라지지는 않습니다.

CPU 경쟁이 원인이면 효과가 있는 경우가 있습니다.
하지만 I/O 대기, 잠금 대기, 절전에 의한 낮은 주파수, E코어 쪽 실행 등이 원인이면 우선순위만으로는 부족합니다.

P코어에 고정하면 항상 정답

항상 정답은 아닙니다.

P코어는 고성능이지만 발열이나 소비 전력도 늘어납니다.
또한 다른 중요한 포그라운드 처리와 경쟁할 가능성도 있습니다.

P코어로 몰아야 할 처리와, E코어로 충분한 처리를 나누는 편이 중요합니다.

절전 설정은 사용자 취향이고, 앱과는 무관하다

관련이 있습니다.

같은 앱이라도 전원 모드, 전원 플랜, EPP, 부스트, Core Parking에 따라 실행 방식이 달라집니다.

특히 노트북에서는 AC 전원과 배터리에서 동작이 달라집니다.

Efficiency mode는 단순히 느리게 할 뿐이다

단순히 느리게 할 뿐은 아닙니다.

낮은 우선순위화와 EcoQoS로, 포그라운드 앱의 응답성과 전력 효율을 지키기 위한 구조입니다.
급하지 않은 백그라운드 처리에는 오히려 적극적으로 생각할 가치가 있습니다.

Windows라서 안정되지 않는다

이것도 거친 시각입니다.

Windows는 실시간 OS가 아닙니다.
하지만 스케줄링, 전원 관리, QoS, 측정, 로그, 스레드 설계를 이해하면, 꽤 현장용으로 안정시킬 수 있습니다.

문제는 “Windows라서 안 된다”가 아니라, 어느 층에서 무엇이 일어나는지를 보지 않는 것입니다.

14. 구현보다 먼저, 로그를 설계한다

이런 문제는 고객 환경에서만 일어나는 경우가 있습니다. 그래서 앱 쪽에 최소한의 진단 정보를 남길 수 있게 해 두면 도움이 됩니다.

예를 들어 진단 로그에는 이런 정보를 냅니다.

• 앱 버전
• Windows 버전
• CPU 이름
• 논리 프로세서 수
• AC 전원인지 배터리인지
• 처리 시간의 평균·최댓값·퍼센타일
• 처리 주기의 지연 횟수
• 대상 스레드의 우선순위
• 프로세스 우선순위
• 선호도 설정 유무
• EcoQoS 설정 유무
• 시작 시의 전원 플랜
• 대상 처리가 타임아웃한 횟수

고객 쪽에서 “가끔 느리다”고 했을 때, 기록이 없으면 추측 싸움이 됩니다. 로그가 있으면 가설을 세울 수 있습니다.

배터리 시에만 느리다
특정 PC에서만 느리다
시작 직후에만 느리다
30분 후부터 느리다
다른 앱 실행 중에만 느리다
일정 주기로 이상치가 나온다

이런 차이가 보이면, 우선순위인지, 선호도인지, 전원 설정인지, 열인지, 다른 대기인지, 가려내기 쉬워집니다.

15. 고무라소프트의 시각

Windows 앱 개발에서는 깔끔한 이론만으로는 부족합니다.

고객의 PC에서 동작할 것.
현장 단말에서 동작할 것.
오래된 주변 기기와 공존할 것.
백신 소프트웨어나 프린터, 사내 정책이 있는 환경에서 동작할 것.
노트북의 절전 설정에서도 무너지지 않을 것.
성능이 필요한 곳에서는 제대로 성능을 낼 것.
급하지 않은 처리에서는 사용자를 방해하지 않을 것.

그러려면 Windows를 단순한 “블랙박스 OS”로 보지 않는 편이 좋습니다.

Windows는 스레드를 어떻게 실행할지 생각하고 있습니다.
어느 CPU에서 실행할지 생각하고 있습니다.
전력과 성능의 균형을 잡고 있습니다.
P코어/E코어 같은 이종 코어를 다루고 있습니다.
포그라운드 앱과 백그라운드 처리를 구별하려 하고 있습니다.

개발자는 그것에 거스르지 말고, 필요한 곳에서 의도를 전해야 합니다.

이 처리는 사용자를 기다리게 하고 있다.
이 처리는 다소 느려도 된다.
이 처리는 주기가 중요하다.
이 처리는 백그라운드에서 조용히 동작하면 된다.
이 처리는 다른 처리를 방해해서는 안 된다.

그런 설계를 우선순위, 선호도, QoS, 절전 설정에 대한 이해로 구체화합니다.

다음에 읽을 글

이 글에서 다룬 것은 CPU 쪽 설정입니다. “느리다”의 원인이 CPU 밖에 있을 때는, 다음 글이 더 지름길입니다.

16. 정리

Windows 앱의 성능은 코드만으로 결정되지 않습니다.

우선순위를 올려도, 선호도로 E코어 쪽에 가 있으면 기대한 대로 동작하지 않습니다.
P코어로 몰아도, 전원 모드가 절전 쪽이면 CPU는 최대 성능을 내지 않습니다.
CPU Sets나 QoS를 생각하지 않고 강한 선호도를 걸면, Windows의 전원 관리나 스케줄러의 빠져나갈 길을 막습니다.
모든 것을 고성능 쪽으로 몰면, 발열, 팬 소음, 배터리 소비, 다른 앱에 대한 영향이 늘어납니다.

Windows 앱 개발에서는 속도뿐 아니라 응답성, 안정성, 소비 전력, 발열, 다른 프로세스와의 공존까지 포함해 설계할 필요가 있습니다.

그러려면 봐야 할 것은 역시 이 네 가지입니다.

우선순위
선호도
P코어 / E코어
절전 설정

그리고 최근 Windows에서는 거기에 EcoQoS나 Efficiency mode도 더해집니다.

걱정할 것은 많습니다.

하지만 걱정을 그대로 불안으로 둘 필요는 없습니다.

걱정을 측정으로 바꾼다.
걱정을 로그로 바꾼다.
걱정을 설계로 바꾼다.
걱정을 테스트 조건으로 바꾼다.

그렇게 하면 Windows는 단순한 변덕스러운 실행 환경이 아니라, 꽤 관찰할 가치가 있는, 현장용 플랫폼이 됩니다.

Windows는 실시간 OS가 아닙니다.
그래도 실행 환경을 이해하고 설계하면, 현장에서 충분히 믿을 수 있는 앱을 만들 수 있습니다.

그리고 그 어려움이야말로 Windows 앱 개발의 재미이기도 합니다.

참고 링크

• 이 글의 샘플 코드 세트(C# / PowerShell / 단위 테스트) - komurasoft-blog-samples (GitHub)
• Scheduling Priorities - Microsoft Learn
• SetProcessAffinityMask function - Microsoft Learn
• SetThreadAffinityMask function - Microsoft Learn
• CPU Sets - Microsoft Learn
• SYSTEM_CPU_SET_INFORMATION structure - Microsoft Learn
• Change the power mode for your Windows PC - Microsoft Support
• Power Policy Settings - Microsoft Learn
• P-states and C-States - Microsoft Learn
• Processor power management options - Microsoft Learn
• CPMinCores - Microsoft Learn
• Quality of Service - Microsoft Learn
• SetThreadInformation function - Microsoft Learn
• Reduce Process Interference with Task Manager Efficiency Mode - Microsoft DevBlogs

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

CPU 우선순위는 어떻게 설정하나요?

우선순위는 프로세스의 우선순위 클래스와 스레드의 상대 우선순위, 이 두 단계로 결정됩니다. Win32 API에서는 프로세스 쪽에 SetPriorityClass, 스레드 쪽에 SetThreadPriority가 있습니다. PowerShell이라면 Get-Process로 가져온 객체의 PriorityClass 속성에 "AboveNormal" 등을 지정할 수 있고, C#에서는 Process.GetCurrentProcess()의 PriorityClass에 ProcessPriorityClass.AboveNormal을 대입합니다. 다만 HIGH_PRIORITY_CLASS나 REALTIME_PRIORITY_CLASS를 상시 사용하면 시스템 전체의 응답성이 나빠지므로 피해야 합니다.

우선순위를 올렸는데 앱이 빨라지지 않는 이유는 무엇인가요?

우선순위는 경쟁이 있을 때 어느 스레드를 먼저 실행할지 정하는 설정이지, CPU를 빠르게 만드는 설정이 아니기 때문입니다. 느린 원인이 디스크 I/O 대기, 네트워크 대기, 잠금 경쟁, GC 정지, UI 스레드 차단, 백신 소프트웨어의 스캔, 또는 절전 설정으로 CPU 주파수가 억제된 상태라면, 우선순위를 올려도 본질적으로는 해결되지 않습니다. 먼저 처리 시간 분포와 전원 상태, 실행 CPU를 기록해 원인을 가려내는 것이 중요합니다.

SetThreadInformation으로 EcoQoS를 설정하면 무슨 일이 일어나나요?

SetThreadInformation에 ThreadPowerThrottling과 THREAD_POWER_THROTTLING_EXECUTION_SPEED를 지정하면, 해당 스레드를 EcoQoS(절전 쪽 QoS)로 다루도록 OS에 알릴 수 있습니다. QoS는 코어 선택이나 프로세서 전원 관리에 영향을 줄 수 있으므로, 백그라운드 동기화나 급하지 않은 로그 집계 같은 처리를 포그라운드 앱을 방해하지 않는 절전 쪽으로 넘길 수 있습니다. 반면 UI 조작에 직결되는 처리나 카메라 캡처, 제어 주기에 관련된 처리에는 신중해야 합니다. StateMask를 0으로 하면 성능 중시로 되돌릴 수 있습니다.

powercfg의 CPMinCores란 무엇인가요?

CPMinCores는 Windows의 Core Parking에 관한 전원 설정으로, 임의의 시점에 논리 프로세서의 최소 몇 %를 un-parked(사용 가능 상태)로 둘지를 지정합니다. 값을 100%로 하면 Core Parking 알고리즘은 비활성화됩니다. 현재 설정은 관리자 권한으로 powercfg /q SCHEME_CURRENT SUB_PROCESSOR를 실행하면 확인할 수 있으며, 선호도로 CPU를 제한한 경우에는 Core Parking의 판단과 어긋나는 상황이 있으므로 둘을 함께 봐야 합니다.

저자 프로필

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

Go Komura

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

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