디자인 가이드

이 PC 열 관리 설계 가이드에서는 "너무 뜨거움" 및 "너무 차가움"에 해당하는 PC 온도 값을 확인하는 방법에 대한 정보를 제공합니다.

이러한 결정을 내리는 것은 좋은 PC 사용자 환경을 제공하는 설계의 주요 요구 사항입니다. 또한 이러한 임계값은 여러 열 영역에 상주하는 PC 구성 요소에 대해 수행할 첫 번째 완화 작업을 선택하는 데 도움이 됩니다.

온도 임계값 설계

변수 및 가정

PC의 열 동작에 영향을 미치는 요인은 다음과 같습니다.

• 하드웨어 설계

  좋은 하드웨어 설계의 중요성은 아무리 강조해도 지나치지 않습니다. 자세한 내용은 하드웨어 열 모델링 및 평가를 참조하세요.

• 환경

  이들은 시스템의 열 동작에 기여하는 외부 요인입니다. 소프트웨어는 열 제약 조건이 문제임을 사용자에게 알리는 것을 통해서만 환경에 영향을 줄 수 있습니다(예: thermal-failure-to-boot 로고 표시). 사용자는 이러한 요소가 변경되도록 하려면 다른 환경으로 이동해야 합니다.

  • 햇빛 방사선

    화면 또는 시스템의 일부에 영향을 미치는 햇빛의 강도와 각도입니다.

  • 주변 온도

    환경의 온도입니다.

  • 기류

    공기 순환 여부. 바람이 많이 부는지 또는 컴퓨터 케이스에 있는지 여부.

  • 습도

    건조한지 또는 습한지 여부.

• 워크로드 및 전력 소비

  여기서는 워크로드와 전력 소비가 서로 비례한다고 가정합니다. 즉, PC 또는 구성 요소가 수행하는 작업이 많을수록 더 많은 전력을 소비하고 더 많은 열을 생성합니다. 모든 경우에 해당되지 않을 수도 있지만 이 간소화된 모델은 여기서 더 많거나 적게 충분합니다. 소프트웨어 완화가 제공되는 곳입니다. 워크로드를 줄임으로써 더 적은 열이 생성되고 PC가 계속 작동합니다.

하드웨어를 설계하고 모델링할 때 이전 목록에 언급된 매개 변수를 고려합니다. 환경에 최악의 경우 값을 사용하세요. 소프트웨어에서 직접 제어할 수 있는 유일한 매개 변수는 워크로드입니다.

열 기본 사항

일정한 워크로드를 실행할 때 PC의 열 동작을 고려합니다. 워크로드가 시작되면 CPU 및 GPU와 같은 PC의 하드웨어 구성 요소가 열을 생성하고 온도를 높입니다. 주변 온도에 비해 온도가 증가함에 따라 PC는 결국 열 생성이 열 방출과 동일할 때까지 더 빨리 열을 방출하기 시작하고 온도가 꾸준한 상태에 도달합니다. 이 상수 워크로드의 전체 기간 동안에는 제한이 없으므로 성능 및 처리량은 일정합니다.

다음 다이어그램은 제한이 없는 경우 열 생성, 온도 및 성능 간의 관계를 보여 줍니다. PC의 온도는 주변 온도 및 제한 온도에 의해 제한되는 열 봉투 내에 유지됩니다.

이제 일정하지만 리소스 집약적인 다른 워크로드를 실행할 때 PC의 열 동작을 고려해 보세요. 이 워크로드가 실행될 때 생성된 열은 시스템이 주변 환경으로 방출할 수 있는 열보다 훨씬 높으며, 그 결과 온도가 꾸준히 상승합니다. 수동 냉각이 없으면 시스템이 너무 뜨거워지고 최종 사용자의 편안함과 안전에 부정적인 영향을 미칠 때까지 온도가 계속 상승합니다. 고온에서는 하드웨어도 손상될 수 있습니다. 열 제한은 PC가 이러한 고온에 도달하지 않도록 하는 데 도움이 됩니다. 미리 정의된 제한 온도 트립 지점에서 온도가 상승하면 시스템이 제한 성능을 시작합니다. 따라서 열 생성 및 소멸이 균등화된 후 시스템 온도가 안정 상태에 도달하면 열 생성이 감소되고 점진적으로 감소됩니다.

다음 다이어그램은 열 발생을 줄이기 위해 성능이 제한될 때의 열 생성, 온도 및 성능 간의 관계를 보여 줍니다.

앞의 다이어그램에 표시된 두 경우 모두 시스템 온도가 안전 제한을 초과하지 않도록 워크로드가 열 봉투 내에서 작동해야 합니다. 봉투는 주변 온도로 시작하고 제한 온도로 끝납니다. 또한 두 경우 모두 열 생성 및 소멸이 결국 균형 잡힌 상태에 도달하고 시스템 온도가 안정화됩니다.

열 봉투 정의

잘 설계된 PC는 가능한 한 많은 열 봉투가 있어야 하며, 그러면 사용자에게 오래 지속되며 완화가 없는 환경을 제공할 수 있습니다. 앞의 다이어그램에 표시된 것처럼 열 봉투는 주변 온도에 의해 결정되는 하한이 있습니다. 이는 제한 온도에 의해 상한이 적용됩니다. 주변 온도는 시스템 디자이너가 제어할 수 있는 변수가 아니지만 하드웨어 설계가 좋은 경우 상한을 더 높일 수 있습니다. 자세한 내용은 하드웨어 열 모델링 및 평가를 참조하세요. 그러나 하드웨어가 주요 제한 사항이 아니라고 가정하더라도 열 봉투를 정의할 때 다른 중요한 요소를 고려해야 합니다.

원하는 운영 범위는 이러한 제한 요인을 잠식하지 않고 가능한 한 커야 합니다.

• 안전

  시스템의 온도는 먼저 사용자가 시스템을 사용하여 부상을 입지 않도록 해야 합니다. 이 요구 사항은 주로 피부 온도 센서에 적용됩니다.

• 하드웨어 보호

  온도는 시스템 구성 요소가 "녹거나" 열로 인한 손상을 유발하는 것을 방지해야 합니다. 이 요구 사항은 주로 프로세서 위에 있는 센서와 같은 구성 요소 온도 센서에 적용됩니다.

• 정부 규제

  모든 시스템은 소비자 전자 제품 안전에 대한 해당 산업 표준(IEC 62368 등)을 충족해야 합니다.

하드웨어 열 모델링 및 평가

하드웨어 설계를 보완하는 소프트웨어

하드웨어를 설계할 때 열 관리를 염두에 두는 것이 중요합니다. 저전력 부품을 선택하고, 핫 구성 요소를 서로 멀리 배치하고, 단열재를 통합하는 것은 하드웨어가 열 환경을 크게 개선할 수 있는 방법의 몇 가지 예에 불과합니다. 이러한 메서드는 소프트웨어에서 바꿀 수 없습니다. 따라서 소프트웨어 솔루션은 전체 열 환경에서 하드웨어 설계를 보완하는 역할만 합니다.

하드웨어 목표

일반적인 워크로드를 실행하려면 어떤 형태의 소프트웨어 열 완화도 필요하지 않습니다. 하드웨어 열 설계는 이러한 워크로드에 대한 열을 분산할 수 있어야 합니다.

모델링

모델링은 이전에 설명한 하드웨어 목표를 달성하기 위한 반복적인 프로세스입니다. 이 프로세스에서는 소프트웨어 완화를 고려하지 마세요. 하드웨어 기능에만 의존하고 필요에 따라 조정합니다.

1. 일반적인 워크로드를 정의합니다. 시스템의 플랫폼에 따라 휴대폰에서 서버까지 각 시스템에는 표준 워크로드 집합이 있어야 합니다. 이러한 워크로드는 HD 비디오 회의와 같은 강렬한 워크로드가 아니라 웹 검색 또는 음악 듣기와 같은 더 평균적인 워크로드여야 합니다.

2. 열이 섀시에 균일하게 분산되지 않으므로 일반적인 워크로드에서 모델 시스템 및 개별 구성 요소 전원 소비. 프로세서와 같이 대부분의 전력을 사용하는 구성 요소에 특히 주의하세요.

3. 워크로드 전력 소비량 예측에 따라 시간이 지남에 따라 구성 요소 및 피부 온도의 상승을 모델링합니다.

4. 시스템의 기계 설계를 조정하여 구성 요소 온도가 모든 주변 온도에 대한 하드웨어 안전 제한 및 사용자 편안함 제한 내에 있는지 확인합니다. 기계적 설계 문제를 해결하기 위한 몇 가지 방법은 다음과 같습니다.

   1. 더 나은 열 전도 재료를 추가하여 열 방출 기능을 향상시킵니다.
   2. 격리 계층을 추가하여 피부와 내부 온도 사이의 델타 온도를 높입니다.

5. 충족될 때까지 1~4단계를 반복합니다.

6. 하드웨어를 빌드하고 평가합니다.

Evaluation

모든 하드웨어 수정에 대해 대표 워크로드에 대한 온도 및 전력 측정을 수행하여 열 동작을 평가해야 하며, 필요에 따라 기계 설계를 수정해야 합니다.

이러한 열 평가를 수행하려면 다음 단계를 수행하는 것이 좋습니다.

1. 열 측정 테스트 매트릭스를 정의합니다.

   1. 행렬은 정상 및 최대 주변 온도를 모두 포함해야 합니다.
   2. 행렬에는 열 모델링의 일부로 식별된 모든 일반적인 워크로드가 포함되어야 하며, 모든 워크로드에 대해 적어도 1시간 동안 데이터를 캡처해야 합니다.
   3. 일관된 결과를 생성하려면 여러 PC에서 행렬을 여러 번 실행해야 합니다.

2. 테스트 매트릭스에 정의된 모든 워크로드에 대해 다음 데이터를 캡처합니다.

   1. 시스템 및 구성 요소 전원 사용량 데이터입니다.
   2. 주변, 내부 구성 요소 및 피부 온도 데이터입니다.
   3. 열 제한, 성능 메트릭 및 프로세서 사용률을 감지하는 소프트웨어 추적입니다.

피부 및 구성 요소 온도 데이터는 시스템이 도달할 수 있는 최대 피부 온도와 이 온도가 허용되는지 여부를 직접 나타냅니다. 중요한 종료 전에 시스템에 얼마나 많은 열 헤드룸이 있을 수 있는지 고려합니다. 성능 메트릭 데이터는 시스템이 필요한 성능을 제공하는지 여부를 결정하는 데 도움이 됩니다. 열 제한 소프트웨어에 의해 기록된 추적 데이터는 열 제한 비율을 보여줍니다. 전력 소비 데이터 및 CPU 사용률 데이터는 온도 변화에 영향을 주는 요인을 결정하는 데 도움이 될 수 있습니다.

다음 표에서는 다음 구성을 사용하여 PC에 대한 이러한 데이터 수집의 예를 제공합니다.

Configuration

• 컴퓨터 이름: 열 테스트-1
• 평균 주변 온도: 23^oC
• 열 영역 트립 지점(_PSV): 80^oC

범주	하위 범주	동영상 스트리밍	캐주얼 게임	어항	3D 게임	TDP
워크로드 설정		Wi-Fi를 통한 전체 화면 720p H.264 비디오 스트리밍	게임 이름 CPU 사용률	물고기 100마리가 있는 클래식 IE	게임 이름 CPU 사용률	CPU 및 GPU 100%
전력 소비	시스템 전원
	SoC 전원
	전원 표시
	백라이트 전원
온도	최대 SoC 온도
	최대 피부 온도
성능 메트릭		평균 프레임 속도	평균 프레임 속도	평균 프레임 속도	평균 프레임 속도

Windows 열 관리 프레임워크

Windows 열 관리 프레임워크는 소프트웨어 열 관리를 위한 포괄적인 솔루션을 제공합니다. 다음 예제에서는 열 관리를 구현하는 방법을 보여 줍니다. 적절한 열 모델링, 유효성 검사 및 효과적인 열 기계 설계를 통해 모든 시스템은 대부분의 대상 주변 온도에서 대부분의 워크로드에서 원활한 사용자 환경을 제공할 수 있어야 합니다. 열 완화가 필요한 경우 Windows는 효과적이고 확장 가능한 열 관리 아키텍처를 제공합니다.

Windows 열 관리는 능동 및 수동 냉각을 모두 지원합니다. 능동 냉각을 통해 팬은 공기를 순환하고 시스템을 냉각하는 데 도움이 되도록 켜집니다. 수동 냉각을 사용하면 과도한 열 조건에 대응하여 장치 성능이 저하됩니다. 성능을 줄이면 전력 소비량이 줄어들어 열이 줄어듭니다.

Windows 열 관리 프레임워크는 시스템 디자이너가 지정한 정책을 사용하여 시스템에 열 관리를 적용합니다. 높은 수준에서 디자이너는 각 열 센서에서 얻은 판독값이 각 구성 요소의 영향을 받는 방식을 지정해야 합니다. 이러한 사양이 없으면 Windows는 시스템을 열적으로 관리할 수 없습니다. 따라서 좋은 열 설계를 달성하기 위해 각 시스템 디자이너가 열적으로 시스템의 특징을 지정하는 것은 각 시스템 디자이너의 책임입니다.

시스템이 Windows 열 관리 프레임워크를 사용할 필요는 없지만 운영 체제와의 긴밀한 통합으로 인해 권장되는 솔루션입니다. 그러나 사용되는 열 관리 솔루션에 관계없이 모든 최신 대기 PC는 진단 목적으로 HCK 요구 사항을 준수해야 합니다.

열 관리 아키텍처

Windows 열 관리 아키텍처는 열 영역의 ACPI 개념을 기반으로 합니다. ACPI 열 영역 모델은 펌웨어, 운영 체제 및 드라이버 간의 협력을 요구합니다. 이 모델은 중앙 열 관리 구성 요소에서 잘 정의된 인터페이스를 통해 센서 및 냉각 장치를 추상화합니다. 열 관리 개선 사항은 ACPI 5.0 사양의 11장을 기반으로 합니다. Windows 열 관리 프레임워크는 이 챕터에 설명된 기능의 하위 집합을 구현합니다.

모델의 필수 구성 요소는 다음과 같습니다.

• 펌웨어를 통해 Windows에 설명된 플랫폼 열 영역 정의입니다. 열 영역은 연결된 온도 값을 갖는 추상 엔터티입니다. 운영 체제는 영역 내의 장치에 열 완화를 적용할 수 있도록 이 온도를 모니터링합니다. 영역에는 열을 생성하는 기능 장치 집합과 성능을 조정하여 열 생성을 제어할 수 있는 장치의 하위 집합이 포함되어 있습니다.
• 지역의 온도를 나타내는 온도 센서입니다. 센서는 펌웨어 또는 Windows 온도 드라이버에서 영역의 온도를 검색하기 위해 읽기 온도 인터페이스를 구현해야 합니다.
• 열 영역 내의 장치에 대한 드라이버가 수동 냉각 작업을 구현할 수 있도록 하는 열 냉각 인터페이스입니다. 각 관리되는 드라이버에는 Windows 열 인프라에 관여하는 냉각 인터페이스가 있어야 합니다.
• 열 영역 정의를 해석하고 필요 시 인터페이스를 호출하여 냉각을 조정하는 중앙 집중식 열 관리자입니다. 열 관리자는 Windows 커널에서 구현되며 시스템 디자이너의 작업이 필요하지 않습니다.

다음 블록 다이어그램은 Windows 열 관리 아키텍처의 개요입니다. 주요 구성 요소는 열 관리자, 열 영역, 관리 드라이버 및 온도 센서입니다. 열 영역은 열 관리자에서 제공하는 제약 조건에 따라 관리되는 장치의 제한 동작을 지시합니다. 열 관리자에서 사용하는 알고리즘은 열 영역에 대한 센서의 온도 판독값을 입력 매개 변수로 사용합니다.

시스템의 열 영역은 ACPI 펌웨어에서 설명하고 ACPI를 통해 열 관리자에 노출되어야 합니다. 구성 정보를 통해 열 관리자는 관리해야 하는 열 영역 수, 각 열 영역 제한을 시작해야 하는 시기 및 영역의 일부인 장치를 알고 있습니다. 온도를 모니터링하기 위해 시스템 디자이너는 ACPI 펌웨어에서 열 알림을 지원합니다.

열 관리자가 열거된 영역에서의 열 이벤트에 대한 알림을 받으면 시스템은 정기적으로 영역의 온도를 평가하고 열 영역의 장치에 적용할 열 제한 성능 비율을 결정하기 시작합니다. 이 평가는 ACPI 사양에 설명된 열 제한 알고리즘에 의해 수행됩니다. 그런 다음 열 관리자는 영역의 모든 장치에 특정 백분율로 성능을 제한하도록 알리고 장치 드라이버는 제한 비율을 장치 클래스별 작업으로 변환하여 성능을 줄입니다. 열 영역 온도가 제한 임계값 온도 아래로 떨어지고 더 이상 제한이 필요하지 않을 때 주기적인 평가 및 제한이 중지됩니다.

피드백 루프

열 관리 아키텍처를 생각하는 또 다른 방법은 입력, 정책 디렉터 및 관리 장치를 사용하는 것입니다. 다음 블록 다이어그램에서 피드백 루프에 대한 입력은 온도 및 전류입니다. 이러한 입력은 구현할 열 정책을 결정하는 데 사용됩니다. 열 관리자는 온도 입력을 단독으로 사용하며 정책 드라이버는 원하는 입력을 사용할 수 있습니다. 그런 다음 열 영역은 해당 정책을 관리되는 드라이버에 적용합니다. 정책이 적용된 후 센서는 해당 값을 업데이트하고 루프를 닫습니다.

다음 블록 다이어그램은 열 응답 모델의 세 단계를 보여줍니다. 온도 및 전류 센서의 입력은 적용할 열 정책을 결정하는 데 도움이 되는 정보를 제공합니다. 이 정책은 관리 드라이버에 적용된 다음 센서의 판독값에 영향을 줍니다. 프로세스는 피드백 루프에서 반복됩니다.

시스템 구현자의 책임

위에서 설명한 대로 완전한 Windows 열 솔루션을 위해서는 여러 구성 요소가 필요합니다. 열 프레임워크의 아키텍처는 하드웨어 공급업체와 시스템 통합자의 책임을 분리할 수 있도록 특별히 설계되었습니다.

파트너가 구현하는 데 필요한 구성 요소는 다음과 같습니다.

• 센서

  온도 센서 드라이버는 하드웨어 공급업체에서 제공해야 합니다. 온도 센서에 의존하는 열 영역에 대한 지식이 필요하지 않다는 점을 감안할 때 해당 기능은 다양한 플랫폼 설계에서 표준이어야 합니다. 현재 센서와 같은 정책 드라이버에 대한 사용자 지정 센서도 하드웨어 공급업체의 책임입니다.

• 열 영역

  열 영역은 하드웨어 공급업체 및/또는 시스템 통합자가 정의할 수 있습니다. 모든 시스템에는 하드웨어 공급업체 또는 시스템 통합자가 수행할 수 있는 중요한 종료 온도(지원되는 경우 최대 절전 모드 온도)를 구현하는 열 영역이 하나 이상 있어야 합니다. 그러나 완화를 위해 특정 장치 또는 피부 온도를 모니터링하는 다른 열 영역의 경우 시스템 통합자가 시스템의 열 동작에 대한 보다 구체적인 지식을 갖추는 것이 일반적입니다. 따라서 이러한 열 영역은 일반적으로 시스템 통합자에 의해 구현됩니다.

• 장치 드라이버용 열 냉각 인터페이스

  열 관리될 장치에 대한 드라이버를 작성하는 개발자도 냉각 인터페이스를 구현해야 합니다. 장치 드라이버는 이 인터페이스를 사용하여 열 관리 프레임워크를 옵트인합니다. 장치 드라이버는 장치의 기능에 대한 특정 지식을 가지고 있습니다. 이러한 동일한 드라이버는 열 영역에서 요청한 작업을 제대로 해석할 수 있도록 열 냉각 인터페이스를 구현해야 합니다.

센서

센서는 열 정책을 결정하는 입력을 제공합니다. Windows는 열 관리자에 대한 입력으로 온도 센서만 지원합니다. 그러나 정책 드라이버는 현재 센서 드라이버와 같은 사용자 지정 드라이버의 입력을 추가로 수행할 수 있습니다.

온도 센서

온도 센서는 다음과 같은 기능 모드를 제공합니다.

• 열 관리자 또는 열 영역의 개입 없이 온도 변화를 지속적으로 모니터링합니다.
• 온도가 _PSV, _HOT 또는 _CRT 정의된 임계값을 초과하면 열 관리자에게 말합니다.
• 온도 쿼리에 응답하고 현재 온도 값을 반환합니다.

다음 다이어그램에서는 제한 중에 온도 모니터링이 작동하는 방식을 보여 줍니다. ACPI 펌웨어 또는 온도 센서 드라이버는 온도가 _PSV, _HOT 또는 _CRT 같은 미리 정의된 임계값에 도달하면 열 관리자에게 알리고 현재 온도에 대한 열 관리자의 정기 쿼리에 응답해야 합니다. 온도 쿼리 기간은 _TSP 의해 정의됩니다.

온도가 임계값을 초과할 때 열 관리자에게 항상 알림을 받도록 하려면 온도 센서 인터럽트는 항상 절전 모드 해제 가능(시스템이 최신 대기 상태이고 SoC가 저전력 상태인 경우에도)이어야 합니다. 온도 센서 인터럽트에서 항상 절전 모드 해제가 가능하지 않은 경우 잠재적인 인터럽트 손실을 방지하기 위해 적어도 인터럽트는 수준 트리거로 구성되어야 합니다.

열 영역에는 열 센서가 하나 이상 있을 수 없지만 여러 열 영역에서 열 센서를 사용할 수 있습니다.

센서 하드웨어가 정확히 +/- 2^oC가 되도록 하는 것이 좋습니다.

_TMP 또는 온도 센서 드라이버가 보고하는 온도는 센서의 실제 값이거나 여러 센서를 기반으로 하는 추정 값일 수 있습니다.

일반적으로 하드웨어 공급업체에서 제공합니다. Windows는 온도 모니터링을 위한 두 가지 구현을 지원합니다.

• 노드 온도 센서
• ACPI 기반

구현 1: 온도 센서 드라이버

온도 센서 드라이버는 단순히 센서의 온도를 보고합니다. ACPI 드라이버는 센서 드라이버와 함께 하나의 뛰어난 IOCTL을 발급하여 트립 지점 중 하나의 교차점을 감지합니다. 또한 ACPI는 현재 온도를 읽기 위한 시간 제한 없이 하나의 IOCTL을 발급할 수 있습니다. 시간 제한 만료를 기다리는 동안 취소된 경우 센서 드라이버는 읽기 IOCTL의 취소를 처리해야 합니다. 온도 센서는 다음 인터페이스를 구현해야 합니다.

typedef struct _THERMAL_WAIT_READ {  
    ULONG Timeout;  
    ULONG LowTemperature;  
    ULONG HighTemperature;  
} THERMAL_WAIT_READ, *PTHERMAL_WAIT_READ;

#define IOCTL_THERMAL_READ_TEMPERATURE\  
        CTL_CODE(FILE_DEVICE_BATTERY, 0x24, METHOD_BUFFERED, FILE_READ_ACCESS)

다음 표에서는 온도 판독 인터페이스에 대한 입력 및 출력 매개 변수에 대해 설명합니다.

매개 변수	설명
Timeout	온도 데이터를 반환하기 전에 대기하는 시간(밀리초)입니다. 0은 대기하지 않고 온도를 즉시 읽어야 했음을 나타냅니다. -1은 읽기 시간이 초과되어서는 안 되었음을 나타냅니다.
LowTemperature	새 온도를 반환하기 위한 하한 임계값입니다. 온도가 낮은 온도 임계값 아래로 떨어지자마자 드라이버는 IOCTL을 완료해야 합니다. 온도가 이미 낮은 온도보다 낮으면 IOCTL을 즉시 완료해야 합니다.
HighTemperature	새 온도를 반환하기 위한 상한 임계값입니다. 온도가 고온 임계값 이상으로 상승하는 즉시 운전자는 IOCTL을 완료해야 합니다. 온도가 이미 고온보다 높은 경우 IOCTL을 즉시 완료해야 합니다.
IOCTL 반환 값	현재 온도를 소수점 아래 첫째 자리 켈빈으로 반환하는 ULONG 크기의 출력 버퍼입니다.

하나의 열 영역 또는 여러 열 영역에서 하나의 온도 센서를 사용할 수 있습니다. 열 영역에 사용할 온도 센서를 지정하려면 열 영역에 열 _DSM 지정해야 하며 함수 2를 구현해야 합니다. (이전 버전과의 호환성을 위해 온도 센서 드라이버를 열 영역 스택 위에 로드할 수 있습니다. 그러나 선호되는 구현은 센서 드라이버를 열 영역 스택과 분리하는 것입니다.) 이 _DSM은 다음과 같이 정의됩니다.

인수Arg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: 버전 = 0 Arg2: 함수 = 2 Arg3: 비어 있는 패키지 Return 열 영역의 온도를 반환할 디바이스에 대한 단일 참조입니다.

열 영역은 또한 _DEP에 있는 온도 센서 장치에 대한 종속성을 지정해야 합니다. 다음은 센서 장치의 _DSM 구현에 대한 간단한 예입니다.

Device(\_SB.TSEN) {
    Name(_HID, "FBKM0001")     // temperature sensor device
}

ThermalZone(\_TZ.TZ01) {
    Method(_DSM, 0x4, NotSerialized){
        Switch (ToBuffer(Arg0)) {
            Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
                Switch (ToInteger(Arg2)) {
                    Case(0) {
                        // _DSM functions 0 and 2 (bits 0 and 2) are supported
                        Return (Buffer() {0x5})
                    }       
                    Case (2) {
                        Return ("\_SB.TSEN")
                    }
                }
            }
        }
    }

    Method(_DEP) {
        Return (Package() {\_SB.TSEN})
    }

    // Other thermal methods: _PSV, etc.

}

자세한 내용은 장치별 Microsoft 열 확장 방법을 참조하세요.

구현 2: ACPI 기반

ACPI 펌웨어는 ACPI 사양에 정의된 대로 _TMP 및 알림 0x80을 지원해야 합니다. 이 방법의 장점은 시스템에 추가 드라이버를 설치할 필요가 없다는 것입니다. 그러나 이 방법은 ACPI 작업 영역을 통해 액세스할 수 있는 리소스와 상호 작용하는 것으로 제한됩니다.

열 정책 제어

열 영역

열 영역은 개별 열 제한 엔터티입니다. 트립 지점, 제한 샘플 속도 및 제한 수식 상수와 같은 자체 열 제한 특성이 있습니다. 하나의 열 영역에는 여러 열 제한 장치가 포함될 수 있으며, 각 장치는 열 영역의 온도 증가에 기여할 수 있습니다. 동일한 열 영역에 있는 모든 장치는 열 영역에 적용되는 것과 동일한 제약 조건을 따라야 합니다.

열 영역 및 해당 매개 변수가 정확하게 정의되도록 하려면 시스템 디자이너는 다음을 수행해야 합니다.

• 시스템의 섀시에서 핫스폿을 식별하고 이러한 핫스폿이 온도 센서에 열을 분산하는 방법을 결정합니다. (이상적으로 열 센서는 피부 온도 센서를 제외하고 시스템의 핫 스폿에 앉아 있습니다.)
• 시스템의 온도 관계를 특성화합니다. 온도 센서 판독값을 구성 요소 온도 및 피부 온도에 매핑합니다.

오버스로틀 임계값

Windows 10부터, Windows 열 관리에 열 영역 상태라는 새로운 기능과 함께 오버스로틀이라는 상태가 도입되었습니다. 열 영역이 장치의 설계 제한 수준을 초과하면 열 관리자는 운영 체제 구성 요소에 시스템이 오버스로틀되었음을 알립니다. 이 알림을 통해 시스템은 열 상태를 개선하기 위해 워크로드를 줄일 수 있습니다.

열 관리자는 오버스로틀 상태에 있는 열 영역 수의 전역 수를 유지 관리합니다. 개수가 0을 초과하면 열 관리자는 시스템에 WNF(Windows 알림 시설) 알림을 보내 오버스로틀되었음을 나타냅니다. 오버스로틀된 영역 수가 0으로 반환되면 열 관리자는 시스템에 또 다른 WNF 알림을 보내 오버스로틀된 영역이 없음을 나타냅니다.

열 영역에 대한 오버스로틀 임계값을 지정하려면 함수 3이 구현된 상태로 열 영역에 열 _DSM을 지정해야 합니다. 이_DSM은 다음과 같이 정의됩니다.

인수Arg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 3 Arg3: 비어 있는 패키지 Return 정수 값과 현재 오버스로틀 임계값이며 백분율로 표시됩니다.

다음은 영역이 제한 수준 0%~49%에서 오버스로틀됨을 나타내는 _DSM 예입니다.

 ThermalZone (TZ4) {
    Name (_HID, "QCOM24AE")
    Name (_UID, 0)
    Name(_TZD, Package (){\_SB.CPU4, \_SB.CPU5, \_SB.CPU6, \_SB.CPU7})
    Method(_PSV) { Return (3530) }
       Name(_TC1, 1)
       Name(_TC2, 1)
       Name(_TSP, 1)
       Name(_TZP, 0)
       // _DSM - Device Specific Method
       // Arg0: UUID Unique function identifier
       // Arg1: Integer Revision Level
       // Arg2: Integer Function Index (0 = Return Supported Functions)
       // Arg3: Package Parameters
       Method(_DSM, 0x4, NotSerialized) {
          Switch (ToBuffer(Arg0)) {
             Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
                Switch (ToInteger(Arg2)) {
                   Case(0) {
                      // _DSM functions 0 and 3 (bits 0 and 3) are supported
                      Return (Buffer() {0x9})
                   }
                   Case (3) {
                      Return (50)  // overthrottled below 50%
                   }
                }
             }
          }
       }
 } // end of TZ4

열 영역을 참조하여 Notify(0x81)를 받으면 오버스로틀 임계값이 다시 읽힙니다.

ACPI 개체 구현

다음 표에서는 열 영역을 정의하기 위해 ACPI 펌웨어에서 구현해야 하는 모든 ACPI 개체를 나열합니다.

범주	Control 메서드
영역 내에 포함된 장치 식별	_TZD 열 영역의 장치를 나열합니다. _PSL (선택 사항) 열 영역의 프로세서를 나열합니다. 프로세서는 그 대신 _TZD에 포함될 수 있습니다. Windows는 두 구현을 모두 지원합니다.
작업을 수행해야 하는 열 임계값 지정	_PSV 제한을 시작할 온도입니다. 자세한 내용은 열 봉투 정의를 참조하세요. _HOT (선택 사항) 운영 체제가 시스템을 최대 절전 모드로 전환할 온도입니다. 최대 절전 모드를 지원하지 않는 시스템의 경우 운영 체제가 중요한 종료를 시작합니다. 사용자 데이터를 저장하는 최대 절전 모드의 이점 때문에 모든 x86/x64 시스템에 대해 하나 이상의 열 영역이 권장됩니다. _CRT 운영 체제에서 중요한 종료를 시작하는 온도입니다. 사용자 모드 알림이 없습니다. 시스템에서 최소 하나의 열 영역에 _CRT가 지정되어 있어야 합니다. 그렇지 않은 경우 시스템이 심각한 온도에 도달하면 시스템이 종료 경로를 통과하지 않습니다. 대신 펌웨어 장애로부터 안전한 트립 지점에 도달하고 운영 체제에서 전원을 꺼낼 수 있습니다.
수동 냉각 동작 설명	_TC1 열 관리자가 온도 변화에 대해 열 제한 성능을 얼마나 적극적으로 적용하는지 제어합니다. _TC2 열 관리자가 현재 온도와 _PSV 사이의 온도 델타에 대해 열 제한 성능을 얼마나 적극적으로 적용하는지 제어합니다. _TSP 영역에 대한 적절한 온도 샘플링 간격(소수점 아래 첫째 자리 초)입니다. 열 관리자는 이 간격을 사용하여 열 제한 성능을 평가하는 빈도를 결정합니다. 0보다 커야 합니다. 자세한 내용은 열 제한 알고리즘을 참조하세요.
능동 냉각 동작 설명	_ACx (선택 사항) 팬을 켤 온도입니다. _AC0이 가장 크며, 큰 값부터 먼저 오는 순서여야 합니다. _ALx 능동 냉각 장치 목록입니다.
능동/수동 냉각 정책 설정	_SCP (선택 사항) 사용자가 선호하는 냉각 정책을 설정하려면 능동 및 수동 냉각이 모두 영역에서 지원되는 경우입니다.
최소 제한 한계	_DSM UUID: 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500을 사용하여 최소 제한 한계를 설정합니다. 이는 Windows 열 프레임워크에 대한 사용자 지정이며 ACPI에 정의되어 있지 않습니다. 자세한 내용은 최소 제한 한계를 참조하세요.
보고서 온도	_TMP 열 영역의 온도를 읽습니다. _HID Windows 온도 드라이버를 로드하는 공급업체 고유의 하드웨어 식별자입니다. _DTI (선택 사항) 플랫폼 펌웨어에 영역의 열 임계값 중 하나가 초과되었음을 알립니다. 이 메서드를 사용하면 펌웨어가 영역의 임계값을 변경하여 하이스테레시스를 구현할 수 있습니다. _NTT (선택 사항) 플랫폼 펌웨어가 _DTI를 통해 알림을 받아야 하는 상당한 온도 변경을 지정하는 경우
열 관리자에게 알림	Notify 0x80 운영 체제에 임계값(_PSV)을 초과했음을 알 수 있습니다. Windows 열 관리자는 열 제어를 시작합니다. Notify 0x81 (선택 사항) 영역의 임계값이 변경되었다는 것을 운영 체제에 말합니다. Windows 열 관리자는 새 값을 사용하도록 자체 업데이트됩니다. 이 메서드는 일반적으로 hysteresis를 구현 하는 데 사용 됩니다.
온도 센서 장치 지정	_DSM UUID 사용: 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500. 자세한 내용은 온도 센서를 참조하세요. _DEP 온도 센서가 참조하는 장치를 로드합니다.

최소 제한 한계

최소 제한 한계는 제한된 장치의 요청된 _PSV 하한을 만드는 Microsoft 열 확장 _DSM 방법입니다. 즉, 열 영역이 제어하는 장치의 성능을 제한하는 정도를 결정합니다. 있는 경우 부팅 시 및 열 영역이 ACPI 알림(0x81)을 수신할 때마다 최소 제한 _DSM이 읽힙니다. 수동 냉각 알고리즘을 반복할 때마다 다음을 사용하여 열 관리자가 영역의 장치에 적용하는 DP(성능 제한) 변경을 계산합니다.

DP [%] = _TC1 × (Tₙ – Tₙ₋₁) + _TC2 × (Tₙ – Tₜ) 다음을 사용하여 실제 성능 제한을 계산합니다.

Pₙ = Pₙ₋₁ – DP MTL(최소 제한 한계)이 구현되면 이 두 번째 수식은 다음으로 변경됩니다.

Pₙ = max(Pₙ₋₁ – DP, MTL) 열 영역에 대한 최소 제한 한계를 지정하려면 함수 1이 구현된 상태로 열 영역에 열 _DSM을 지정해야 합니다. 이_DSM은 다음과 같이 정의됩니다.

인수Arg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 1 Arg3: 비어 있는 패키지 Return 정수 값과 현재 최소 제한 한계이며 백분율로 표시됩니다.

다음은 제한을 50% 이하로 제한하는 _DSM의 간단한 예입니다.

ThermalZone(\_TZ.TZ01) {
    Method(_DSM, 0x4, NotSerialized) {
        Switch (ToBuffer(Arg0)) {
            Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
                Switch (ToInteger(Arg2)) {
                    Case(0) {
                        // _DSM functions 0 and 1 (bits 0 and 1) are supported
                        Return (Buffer() {0x3})
                    }       
                    Case (1) {
                        Return (50)
                    }
                }
            }
        }
    }

커널의 열 관리자

Windows 열 관리자는 Windows 커널의 일부로 구현됩니다. 모든 열 영역의 온도를 모니터링하고 적절하게 열 제한을 적용합니다.

열 관리자가 현재 온도에 대해 ACPI 드라이버를 쿼리할 때마다 열 영역의 모든 열 제한 장치에 적용해야 하는 열 제한 성능 비율에 대한 계산을 수행합니다. 열 제한은 수동 냉각 임계값(_PSV)을 초과할 때 평가 및 적용되며, 온도가 그 아래로 냉각되고 열 제한이 100%로 반환될 때까지 모든 온도 샘플링 간격(_TSP)에서 적용됩니다. 하드웨어는 _PSV가 초과된 시기를 감지해야 하며 하드웨어 ACPI 이벤트 알림을 통해 신호를 보내야 합니다.

열 제한 알고리즘

열 제한 알고리즘은 ACPI 사양에 정의된 다음 수식을 사용합니다.

DP [%] = _TC1 × ( Tₙ – Tₙ₋₁ ) + _TC2 × (Tₙ – Tₜ) 참고 사항

Tn = 열 영역에 있는 온도 센서의 현재 온도 판독값(소수점 아래 첫째 자리 켈빈)입니다. Tn𔖃= 이전 판독값의 온도입니다. Tt = 소수점 아래 첫째 자리 켈빈를 대상으로 합니다(_PSV). DP = 성능 변경이 필요합니다. 이 값은 영역의 각 냉각 장치에 적용할 0(완전히 제한됨)에서 100%(할당되지 않음) 사이의 선형 값입니다. 이 수식에서는 온도 변경과 제한 성능 간의 피드백 루프에 대해 설명합니다. 루프의 각 반복에서 현재 온도와 이전 온도 판독값 사이의 온도 델타를 사용하려면 성능 P가 DP 백분율로 감소해야 합니다. DP 값은 적용할 열 제한의 양입니다. 많은 냉각 장치에는 냉각 완화에 대한 선형 열 응답이 없습니다. 이러한 장치에서 열 제한은 장치에 필요한 냉각량을 나타내는 힌트입니다. 각 냉각 장치는 이 선형 값을 장치별 열 완화에 자체적으로 매핑합니다. 장치 성능을 제한하면 전력 소비와 열 발생이 감소하여 온도가 저하됩니다.

두 상수인 _TC1 및 _TC2는 이 피드백 루프에서 열 제한이 얼마나 적극적으로 적용되는지 제어합니다. 더 큰 _TC1 안정적인 온도를 유지하기 위해 더 적극적으로 열 제한이 사용됨입니다. _TC2가 클수록, 온도를 트립 지점 근처까지 미는 데 열 제한이 더 적극적으로 사용됩니다.

다음 표에서는 열 관리자가 DP를 계산하고 적용하는 방법의 예를 제공합니다. 이 예제에서는 다음 매개 변수 값을 사용합니다.

Configuration

• _PSV = 325^oK
• _TC1 = 2
• _TC2 = 3
• _TSP = 5000밀리초
• 온도가 5초마다 지속적으로 1도 상승하는 것으로 가정합니다.

다음 표의 맨 오른쪽 열(레이블이 P)은 이러한 매개 변수에 지정된 제약 조건을 적용하여 발생하는 제한된 성능 수준을 나타냅니다.

반복	시간	테네시	DP	P
1	0초	326oK	= 2 × 1 + 3 × 1 = 5%	95%
2	5초	327oK	= 2 × 1 + 3 × 2 = 8%	87%
3	10초	328oK	= 2 × 1 + 3 × 3 = 11%	76%
4	15초	320oK	= 2 × 1 + 3 × 4 = 14%	62%
5	20초	330oK	= 2 × 1 + 3 × 5 = 17%	45%
...

정책 드라이버

기본적으로 ACPI 사양에 따라 제한 백분율을 결정하는 데 사용되는 알고리즘은 모든 열 영역에 사용됩니다. 앞서 설명한 대로 이 알고리즘은 열 영역에 연결된 온도 센서만을 기반으로 하며, 이는 제한될 수 있습니다.

다른 알고리즘이 선호되는 경우 시스템 디자이너는 정책 드라이버를 구현하여 기본 설정 알고리즘을 구현할 수 있습니다. 정책 드라이버는 제어하는 영역의 열 영역 스택 위에 있습니다. 이 영역의 경우 열 관리자의 ACPI 알고리즘 대신 정책 드라이버 알고리즘을 사용할 수 있습니다. 정책 드라이버 알고리즘에는 입력으로 액세스할 수 있는 모든 정보를 고려하는 기능이 있습니다. 운전자가 내린 정책 결정은 열 관리자에게 전달되어 정보를 기록하고 이를 수행하기 위해 열 영역에 전달합니다.

열 영역에 정책 드라이버를 사용한다는 것은 ACPI가 아닌 운영 체제가 아닌 정책 드라이버가 영역을 제한할 시기와 크기를 결정하는 데 전적으로 책임이 있음을 의미합니다.

정책 드라이버가 있는 경우 모든 트립 지점, 모든 열 상수, 최소 제한 한계 등은 완전히 무시됩니다. 운영 체제는 열 영역이 현재 제한 수준에서 설정되는 이유에 대한 인사이트를 제공하지 않습니다. 일부 이점은 독점 솔루션 대신 정책 드라이버를 사용할 때 제공됩니다. 정책 드라이버는 장치를 제한하는 기본 제공 프로세스를 활용합니다. 열 영역이 열 완화를 제공하기 위해 수행할 수 있는 모든 작업은 정책 드라이버에서 수행할 수 있습니다. 또한 Windows 열 관리에 대한 진단은 자동으로 상속됩니다.

열 정책 인터페이스는 영역이 오버스로트되었는지 여부를 나타내는 새 매개 변수를 포함하도록 업데이트되었습니다. 이 매개 변수는 FALSE로 초기화됩니다. 이전 정책 드라이버는 새 매개 변수를 인식하지 못하며 새 드라이버는 '2'의 정책 버전을 검색할 때 새 매개 변수가 지원된다는 것을 알게 됩니다.

#define TZ_ACTIVATION_REASON_THERMAL      0x00000001  
#define TZ_ACTIVATION_REASON_CURRENT      0x00000002

#define THERMAL_POLICY_VERSION_1          1
#define THERMAL_POLICY_VERSION_2          2

typedef struct _THERMAL_POLICY {  
    ULONG           Version;  
    BOOLEAN         WaitForUpdate;  
    BOOLEAN         Hibernate;  
    BOOLEAN         Critical;  
    ULONG           ActivationReasons;  
    ULONG           PassiveLimit;  
    ULONG           ActiveLevel;
    BOOLEAN         OverThrottled;  
} THERMAL_POLICY, *PTHERMAL_POLICY;

정책 드라이버는 OverThrottled 매개 변수를 TRUE로 설정해서 정책 IOCTL을 완료하여 열 영역이 오버스로틀되었음을 나타낼 수 있습니다. 열 조건이 개선되면 열 정책 드라이버는 열 영역이 복구되었음을 나타내기 위해 OverThrottled를 FALSE로 재설정하여 IOCTL을 완료할 수 있습니다. Windows는 오버스로틀 플래그가 설정된 경우 정책 드라이버가 제한하도록 요구하지 않습니다.

열 관리 장치

열 영역은 커널 모드 드라이버를 통해 관리 장치의 열 동작을 제어합니다. 하나의 열 제한 장치가 여러 열 영역에 상주할 수 있습니다. 여러 열 영역이 서로 다른 열 제한 성능 비율을 요청하는 경우 열 관리자는 열 제한 장치에 적용할 최소 열 제한 성능 비율을 선택합니다.

많은 냉각 장치에는 냉각 완화에 대한 선형 열 응답이 없습니다. 이러한 경우 열 제한은 장치에 필요한 냉각 정도에 대한 힌트입니다. 각 냉각 장치는 이 선형 값을 특정 열 완화에 자체적으로 매핑합니다.

각 장치 드라이버가 로드되면 ACPI는 열 냉각 인터페이스를 쿼리하고 각 응답 장치를 냉각 장치로 등록합니다. 나중에 수동 냉각이 진행 중이고 영역에 대한 열 제한이 변경되면 ACPI는 영역의 각 냉각 장치에서 이 인터페이스를 호출합니다. 냉각 장치는 제공된 열 제한을 특정 냉각 특성에 매핑하고 적절한 냉각 완화를 구현합니다. 냉각 장치가 여러 열 영역에 표시되는 경우 장치를 가장 제한하는 열 제한(즉, 가장 낮은 비율)이 장치에 전달됩니다.

참고 Windows는 프로세서, 백라이트 및 ACPI 제어 방법 배터리에 대한 열 제한의 기본 제공 구현을 제공합니다.

열 냉각 인터페이스

Windows는 장치 드라이버가 열 제한 장치로 등록하고 열 제한 백분율 요청을 수신할 수 있는 확장 지점을 제공합니다. 그런 다음 장치는 해당 백분율을 자신에게 적합한 작업으로 변환할 책임이 있습니다.

열 제한 장치로 추가하려는 장치는 먼저 열 영역 열 장치 목록에 _HID를 추가한 후, 다음과 같은 인터페이스 집합을 구현해야 합니다. 각 장치 드라이버가 로드되면 ACPI는 이 인터페이스를 쿼리하고 응답하는 각 장치를 냉각 장치로 등록합니다. 나중에 수동 냉각이 진행 중이고 영역에 대한 열 제한이 변경되면 ACPI는 영역의 각 냉각 장치에서 이 인터페이스를 호출합니다. 냉각 장치는 제공된 열 제한을 특정 냉각 특성에 매핑하고 적절한 냉각 완화를 구현합니다. 냉각 장치가 여러 열 영역에 표시되는 경우 장치를 가장 제한하는 열 제한(즉, 가장 낮은 비율)이 장치에 전달됩니다.

//  
// Thermal client interface (devices implementing  
// GUID_THERMAL_COOLING_INTERFACE)  
//

typedef  
_Function_class_(DEVICE_ACTIVE_COOLING)  
VOID  
DEVICE_ACTIVE_COOLING (  
    _Inout_opt_ PVOID Context,  
    _In_ BOOLEAN Engaged  
    );  

typedef DEVICE_ACTIVE_COOLING *PDEVICE_ACTIVE_COOLING;  

typedef  
_Function_class_(DEVICE_PASSIVE_COOLING)  
VOID  
DEVICE_PASSIVE_COOLING (  
    _Inout_opt_ PVOID Context,  
    _In_ ULONG Percentage  
    );  

typedef DEVICE_PASSIVE_COOLING *PDEVICE_PASSIVE_COOLING;  

typedef struct _THERMAL_COOLING_INTERFACE {  
    //  
    // generic interface header  
    //  
    USHORT Size;  
    USHORT Version;  
    PVOID Context;  
    PINTERFACE_REFERENCE    InterfaceReference;  
    PINTERFACE_DEREFERENCE  InterfaceDereference;  
    //  
    // Thermal cooling interface  
    //  
    ULONG Flags;  
    PDEVICE_ACTIVE_COOLING ActiveCooling;  
    PDEVICE_PASSIVE_COOLING PassiveCooling;  
} THERMAL_COOLING_INTERFACE, *PTHERMAL_COOLING_INTERFACE;  

#define THERMAL_COOLING_INTERFACE_VERSION 1

프로세서

프로세서의 경우 열 관리자는 열 제한 백분율을 프로세서 전원 관리자(PPM)와 통신합니다. 프로세서의 열 제한은 Windows 기본 제공 기능입니다.

프로세서 집계

프로세서 집계 장치는 열 완화 수단으로 코어 파킹을 허용합니다. 프로세서 집계 장치가 열 영역의 구성원인 경우 영역은 코어 파킹을 열 완화로 지정할 수 있습니다. 코어 파킹이 발생하려면 프로세서를 제한할 필요가 없습니다. 이 구현은 LPI(논리 프로세서 유휴)와 병렬로 작동합니다. 이것은 여전히 코어 파킹의 주의 사항이 적용됩니다. 특히, 파킹된 코어에 선호되는 모든 작업으로 인해 코어가 실행됩니다.

Device(\_SB.PAGR) {
    Name(_HID, "ACPI000C")
}
ThermalZone(\_TZ.TZ01) {
    Name(_TZD, Package() {"\_SB.PAGR"})
    // Other thermal methods: _PSV, etc.
}

그래픽

타사 그래픽 미니포트 드라이버를 열적으로 관리하려면 Windows 그래픽 포트 드라이버인 Dxgkrnl.sys와 상호 작용해야 합니다. Dxgkrnl.sys는 열 냉각 인터페이스를 가지고 있으며 스택 아래로 모든 제한 요청을 미니 포트 드라이버에 전달합니다. 미니포트 드라이버가 요청을 해당 장치와 관련된 작업으로 변환하는 것은 미니포트 드라이버의 책임입니다.

다음 블록 다이어그램은 GPU를 제어하는 열 영역의 아키텍처를 보여 줍니다.

백라이트

백라이트를 줄이면 모바일 플랫폼의 열 조건을 크게 향상시킬 수 있습니다. 작동하는 동안 시스템 디스플레이 밝기는 열적으로 100니트 미만으로 제한되지 않습니다.

백라이트 제어의 경우 열 관리자는 열 제한 백분율을 모니터 드라이버에 Monitor.sys. Monitor.sys는 이 열 입력 및 Windows에 대한 다른 입력에 따라 실제 백라이트 수준 설정을 결정합니다. 그런 다음 Monitor.sys ACPI 또는 디스플레이 드라이버를 통해 백라이트 수준 설정을 적용합니다.

백라이트를 포함하는 열 영역 온도가 계속 상승하면 요청된 열 제한 비율이 결국 0%로 떨어질 수 있습니다. ACPI 또는 디스플레이 드라이버의 백라이트 수준 구현은 성능 제어에 사용할 수 있는 최소 밝기 수준이 최종 사용자에게 계속 표시되도록 해야 합니다.

참고 작동하는 동안 시스템 디스플레이 밝기는 열적으로 100니트 미만으로 제한되지 않습니다.

배터리

시스템의 또 다른 주요 열원은 배터리 충전입니다. 사용자의 관점에서 볼 때, 제한된 열 조건에서 충전을 줄이고 완전히 중단해야 합니다. 그러나 일반적인 사용 사례에서는 배터리 충전을 방해해서는 안 됩니다.

참고 시스템이 (1) 유휴 상태이고 주변 온도 범위가 35^oC 미만인 동안 또는 (2) 주변 온도가 25^oC 미만인 동안에는 배터리 충전이 제한되지 않는 것이 좋습니다.

Windows 제어 방법 배터리 미니클래스 드라이버인 Cmbatt.sys 위에서 설명한 대로 열 냉각 인터페이스를 직접 사용합니다. 펌웨어는 충전에 참여할 때 현재 열 제한을 고려해야 합니다. 충전을 위한 열 제한을 설정하려면 새로운 ACPI 제어 방법이 필요합니다. 이 메서드는 ACPI 5.0 사양 섹션 9.14.1에 정의된 바와 같이 _DSM(Device Specific Method)으로 구현됩니다.

열 제한 비율을 적용하기 위해 Cmbatt.sys _DSM(Device Specific Method) 제어 방법을 평가하여 ACPI 펌웨어에 충전에 대한 열 제한을 설정하도록 요청합니다. _DSM 제어 방법 내에서 열 제한을 나타내기 위해 GUID가 정의됩니다.

Arg #	값	설명
Arg0	4c2067e3-887d-475c-9720-4af1d3ed602e	UUID
Arg1	0	수정 버전
Arg2	1	함수
Arg3	0에서 100 사이의 정수 값입니다.	배터리 충전에 대한 열 제한입니다. 계산된 백분율 수동 제한에 해당합니다.
반환 값	해당 없음	반환 값이 없습니다.

능동 냉각

운영 체제의 관점에서 플랫폼에는 팬 제어를 구현하는 데 사용할 수 있는 두 가지 전략이 있습니다.

• 능동 트립 지점이 있는 하나 이상의 ACPI 열 영역을 구현하여 팬을 연결/해제합니다.

  Windows 열 프레임워크는 매우 기본적인 수준에서 능동 냉각 장치를 지원합니다. 지원되는 유일한 장치는 ACPI 팬이며 온/오프 신호로만 제어할 수 있습니다.

• 전용 솔루션을 구현하여 팬을 제어합니다(드라이버, 포함된 컨트롤러 등을 통해).

  Windows는 팬에 대한 독점 솔루션의 동작을 제어하지는 않지만 Windows는 진단 정보 및 원격 분석을 수집할 수 있도록 포함된 컨트롤러를 포함한 모든 구현에 대해 열 관리자에 대한 팬 알림을 지원합니다. 따라서 운영 체제에 대한 팬 노출은 모든 최신 대기 PC에 필요하며 다른 모든 PC에 대해 강력하게 권장됩니다.

능동 냉각 구현은 앞에서 설명한 수동 냉각 완화와 완전히 별개입니다.

ACPI 열 영역별 팬 제어

Windows는 ACPI 1.0 D 상태 기반 팬 정의를 지원합니다. (자세한 내용은 ACPI 사양을 참조하세요.) 따라서 제어는 팬 켜기 및 끄기로 제한됩니다. 팬의 드라이버는 Windows ACPI 드라이버인 Acpi.sys에 제공됩니다.

1. 온도 센서는 온도가 트립 지점을 초과했음을 읽고 연결된 열 영역에서 Notify(0x80)를 실행합니다.
2. 열 영역은 _TMP 제어 방법으로 온도를 읽고 온도를 능동 트립 지점(_ACx)과 비교하여 팬이 켜지거나 꺼야 하는지 여부를 결정합니다.
3. 운영 체제는 팬 장치를 D0 또는 D3에 배치하여 팬을 켜거나 끕니다.

다음 블록 다이어그램은 ACPI 열 영역으로 제어되는 팬의 제어 흐름을 보여줍니다.

Scope(\_SB) {
    Device(FAN) {
        Name(_HID, EISAID("PNP0C0B"))
        // additional methods to turn the fan on/off (_PR0, etc.)
    }

    ThermalZone(TZ0) {
        Method(_TMP) {...}
        Name(_AC0, 3200)
        Name(_AL0, Package() {\_SB.FAN})
    }
}

ACPI의 다중 속도 팬

ACPI 1.0을 사용하여 팬에 대해 여러 속도를 달성하려면 다음 두 가지 옵션이 있습니다.

• 열 영역은 하나의 실제 팬만 있는 경우 여러 "팬"을 포함할 수 있습니다. 한 번에 더 많은 "팬"을 보유하는 것은 더 빠른 팬 속도로 변환됩니다. 자세한 내용은 ACPI 5.0 사양의 섹션 11.7.2에서 이 옵션의 예를 참조하세요.
• 팬이 켜지면 회전 속도를 스스로 결정할 수 있습니다. 예를 들어 포함된 컨트롤러가 있는 시스템은 이 옵션을 선택할 수 있습니다.

팬의 독점 솔루션

Windows는 구현 중 하나를 사용하여 팬 활동을 감지할 수 있어야 합니다. 플랫폼에서 ACPI 열 모델을 사용하는 경우 Windows는 팬을 켜고 끄는 역할을 하므로 활성 상태일 때 이미 알고 있습니다. 독점 솔루션을 사용하여 팬을 제어하는 경우 Windows에는 팬이 실행 중이라는 알림을 요구합니다. 이를 가능하게 만들기 위해, Windows는 다음 표에 나열된 ACPI 4.0 팬 확장의 부분 집합을 지원합니다.

기능	Description	지원됨
_FST	팬의 상태를 반환합니다.	예
Notify(0x80)	팬의 상태가 변경되었음을 나타냅니다.	예
_FIF	팬 장치 정보를 반환합니다.	아니요
_FPS	팬 성능 상태 목록을 반환합니다.	아니요
_FSL	팬 성능 상태(속도)를 설정합니다.	아니요

Windows는 _FST 개체를 사용하여 팬이 실행 중인지(컨트롤 필드가 0이 아닌 경우) 또는 끄기(컨트롤 필드가 0임)를 확인합니다. Windows는 또한 _FST가 변경되었으며 재평가가 필요하다는 표시로 팬 장치에서 Notify(0x80)를 지원합니다.

_FST 개체를 구현하는 팬은 열 영역의 _ALx 장치 목록에 있을 필요는 없지만 옵션으로 이 목록에 있을 수 있습니다. 이 옵션을 사용하면 일반적으로 팬이 타사 드라이버에 의해 제어되지만 타사 드라이버가 설치되지 않은 경우 OS 열 영역으로 제어할 수 있는 하이브리드 솔루션을 사용할 수 있습니다. 팬이 _ALx 장치 목록에 있고 열 영역(D0에 배치됨)에 연결된 경우 0이 아닌 컨트롤 값을 나타내려면 _FST 개체가 필요합니다.

Windows는 모든 팬에 대해 다음 알고리즘을 사용하여 팬의 상태를 결정합니다.

1. 팬이 D0에 있는 경우(열 영역의 _ACx 트립 지점이 교차한 결과) 연결됩니다.
2. 팬이 D3에 있고 ACPI 4.0 확장을 지원하지 않는 경우 해제됩니다.
3. 팬이 D3에 있고 ACPI 4.0 확장을 지원하는 경우 운영 체제는 _FST 제어 필드에서 0이 아닌 값을 확인하여 팬이 사용 중인지 확인합니다.

예제 1: 하드웨어 팬 컨트롤

이 예제에서 팬은 포함된 컨트롤러에 의해 제어됩니다.

1. 포함된 컨트롤러는 자체 내부 알고리즘에 따라 팬을 시작하거나 중지하기로 결정합니다.
2. 팬을 시작하거나 중지한 후 포함된 컨트롤러는 팬 장치에서 Notify(0x80)를 발급합니다.
3. 운영 체제는 _FST를 평가하고 팬의 새 상태를 읽습니다.

다음 블록 다이어그램은 포함된 컨트롤러에서 제어하는 팬의 제어 흐름을 보여줍니다.

다음 ASL 예제는 운영 체제에 팬 상태의 변경 내용을 알릴 수 있는 "FAN" 장치를 정의합니다.

Scope(\_SB) {
    Device(FAN) {
        Name(_HID, EISAID("PNP0C0B"))
        Name(_FST, Package() {0, 0, 0xffffffff})

        // \_SB.FAN.SFST called by EC event handler upon fan status change
        Method(SFST, 1) {
            // Arg0 contains the new fan status
            Store(Arg0, Index(_FST, 1))
            Notify(\_SB.FAN, 0x80)
        }
    }

    // Omitted: EC event handler
}

예제 2: 드라이버 팬 컨트롤

이 예제에서는 타사 드라이버가 팬을 제어합니다.

1. 드라이버는 자체 내부 알고리즘에 따라 팬을 시작하거나 중지하기로 결정합니다.
2. 드라이버는 팬의 상태를 수정하고 열 장치에서 SFST(사용자 지정 제어 방법)를 평가합니다.
3. 열 장치 제어 방법은 팬 장치의 _FST 콘텐츠를 업데이트하고 팬 장치에서 Notify(0x80)를 발급합니다.
4. 운영 체제는 _FST를 평가하고 팬의 새 상태를 읽습니다.

다음 블록 다이어그램은 타사 드라이버에서 제어하는 팬의 제어 흐름을 보여 줍니다.

Scope(\_SB) {
    Device(FAN) {
        Name(_HID, EISAID("PNP0C0B"))
        Name(_FST, Package() {0, 0, 0xffffffff})
    }

    Device(THML) {
        Name(_HID, "FBKM0001")
        Method(SFST, 1) {
            // Arg0 contains the new fan status
            Store(Arg0, Index(\_SB.FAN._FST, 1))
            Notify(\_SB.FAN, 0x80)
        }
    }
}

팬 존재 여부

플랫폼은 ACPI 네임스페이스에 팬 장치(PnP ID PNP0C0B)를 포함하여 시스템에 팬이 있음을 나타냅니다. Windows는 이 장치가 있으면 시스템에 팬이 있다는 것으로, 그리고 이 장치가 없으면 시스템에 팬이 없다는 것으로 받아들입니다.

최신 대기 관련 지침

Windows 열 관리 프레임워크는 커널의 일부이며 모든 Windows 시스템과 함께 제공됩니다. 따라서 위의 자료는 모든 컴퓨터에 적용됩니다. 그러나 다양한 유형의 컴퓨터에는 최신 대기에 보다 구체적인 추가 지침이 필요합니다.

최신 대기는 PC에 스마트폰 전원 모델을 제공합니다. 사용자가 휴대폰에서 기대하는 즉각적인 사용자 환경을 제공합니다. 휴대폰과 마찬가지로 최신 대기 모드를 사용하면 적절한 네트워크를 사용할 수 있을 때마다 시스템을 최신 상태로 유지하고 연결할 수 있습니다. Windows 10은 특정 Windows 인증 요구 사항을 충족하는 저전력 플랫폼에서 최신 대기를 지원합니다.

최신 대기 PC는 얇고 가벼운 폼 팩터의 고도로 모바일 장치입니다. 또한 최신 대기 PC는 항상 켜져 있고 ACPI S0 상태에 있습니다. 강력하고 신뢰할 수 있는 고객 환경을 제공하려면 기계 설계에서 펌웨어 및 소프트웨어 구현에 이르는 전체 시스템을 열 특성에 주의하여 설계해야 합니다. 따라서 모든 최신 대기 PC는 열 요구 사항을 준수해야 합니다.

최신 대기 요구 사항

모든 최신 대기 PC는 다음 HCK 테스트를 통과해야 합니다.

• 모든 최신 대기 PC에는 중요한 종료 온도(_CRT)가 정의된 열 영역이 하나 이상 있어야 합니다. x86 시스템의 경우 중요한 최대 절전 모드 온도(_HOT)를 정의하여 사용자 데이터 저장을 트리거하는 것이 좋습니다. _HOT는 _CRT보다 낮아야 하며 _CRT 펌웨어 장애로부터 안전한 열 트립 지점보다 낮아야 합니다.
• 각 열 영역은 센서(_TMP)의 실제 온도를 보고해야 합니다. 이 테스트는 PC에서 다양한 워크로드를 실행하며 온도가 변경될 것으로 예상됩니다.

또한 각 PC에는 SoC용 온도 센서가 하나 이상 포함되어 있는 것이 좋습니다.

능동 냉각 요구 사항

팬을 사용하는 최신 대기 PC는 HCK에서 테스트되는 다음과 같은 추가 요구 사항을 준수해야 합니다.

• 팬은 운영 체제에 노출되어야 합니다. 자세한 내용은 팬 존재 여부를 참조하세요.
• 운영 체제는 팬이 켜져 있는지 또는 꺼져 있는지 항상 알고 있어야 합니다. 최신 대기에서 유휴 복원력이 있는 경우에도 팬 활동의 변경 내용이 SoC를 해제하여 상태를 업데이트해야 합니다. 팬 알림을 구현하는 방법에 대한 자세한 내용은 ACPI 열 영역별 팬 제어를 참조하세요.
• PC가 최신 대기 상태일 때는 팬을 켜면 안됩니다. 화면이 꺼질 때마다 최신 대기 중에 현실적인 워크로드가 있는 경우 팬을 켜면 안됩니다.

사용자 관점에서 PC는 최신 대기 상태일 때 꺼져 있는 것처럼 보입니다. 사용자는 최신 대기 상태의 PC가 시스템 "절전 모드" 상태인 것처럼 동작하기를 기대합니다. 따라서 사용자는 수면 중 기존 PC와 마찬가지로 팬이 절대 켜지지 않을 것으로 기대합니다. 팬이 켜지면 사용자가 그 소리를 듣거나 뜨거운 공기가 순환하는 것을 느끼고 컴퓨터가 제대로 작동하지 않는다고 생각할 수 있습니다. 따라서 팬은 최신 대기 상태일 때 켜서는 안 됩니다. 필요한 동작에 대한 자세한 내용은 최신 대기 PC에 대한 HCK 테스트 요구 사항을 참조하세요.

이러한 요구 사항은 화면이 켜져 있을 때의 냉각 정책이 화면이 꺼졌을 때와 달라야 할 수 있다는 것을 의미합니다. PC는 화면이 켜지는 동안 능동 냉각을 사용할 수 있지만 화면이 꺼져 있을 때 수동 냉각에만 의존해야 합니다. 팬의 능동 트립 지점은 화면이 꺼져 있을 때보다 켜져 있을 때 훨씬 낮을 수 있습니다. ACPI 구현의 경우 최신 대기 항목에서 _ACx를 업데이트해야 합니다. 독점 솔루션의 경우 포함된 컨트롤러에서 정책을 업데이트해야 합니다.

프로세서 제한

PPM 최대, 원하는 최소 성능 수준을 PEP에 전달합니다. 열 제한 조건에서 최대 성능 수준은 열 관리자가 요청한 제한 성능과 같아야 합니다. 그런 다음 PEP는 PPM 성능 수준 요구 사항에 따라 CPU의 물리적 전압 및 주파수를 설정합니다.

팬 소음 신호

Windows 11부터 디바이스는 사용자에게 시원하고 조용한 환경을 제공하는 것을 목표로 리소스 관리 결정에 사용하기 위해 OS에 팬 소음 신호를 보낼 수 있습니다. 이 옵트인 인터페이스를 사용하면 펌웨어가 팬 RPM 정보를 0(팬 끄기)에서 최대 RPM까지의 값으로 OS에 보낼 수 있습니다. OS는 필요에 따라 디바이스를 냉각하기 위한 리소스 관리 결정에 이를 사용할 수 있습니다. 이는 다음 두 가지 주요 이점에 기여합니다.

1. 조용한 사용자 환경: 팬 소음과 뜨거운 바람은 고객 불만의 중요한 원인입니다. 이는 디바이스가 적은 양의 작업을 실행하거나 포그라운드 작업을 실행하지 않는 경우와 같이 사용자가 많은 팬 활동을 예상하지 않는 경우에 특히 그렇습니다.
2. 향상된 배터리 수명: 팬 속도가 높으면 전력 사용량이 증가하여 DC에서는 배터리 소모가 빨라지고 AC에서는 충전 속도가 느려집니다.

현재 이 신호를 사용하여 검색 인덱서 작업을 관리할 수 있으며 추가 백그라운드 작업에서도 이 신호를 사용할 수 있도록 할 계획입니다.

다음 다이어그램은 펌웨어에서 소프트웨어로 계층에서 팬 소음 신호가 전송되는 방식을 요약합니다.

팬 소음 신호 작동 방식

ACPI 인터페이스 세부 정보

다음은 이 기능을 지원하기 위해 사용되는 디바이스별 방법(_DSM, UUID: A7611840-99FE-41ae-A488-35C75926C8EB)의 4가지 기능입니다. _FST(팬 상태)에 대한 정보는 ACPI 사양의 섹션 11.3.1.4와 열 관리 디바이스의 예 1: 하드웨어 팬 제어에서 찾을 수 있습니다.

다음 다이어그램은 이러한 함수가 사용되는 흐름을 요약한 것입니다.

다음 블록 다이어그램은 Notify(0x80) 제어 방법을 포함하여 포함된 컨트롤러가 제어하는 팬의 제어 흐름을 보여 줍니다.

참고

팬 소음 신호는 팬 RPM을 제어하지 않고 대신 우선 순위 작업을 완료하기 위해 백그라운드 작업에서 CPU 리소스를 이동해야 하는 팬 소음이 있음을 OS에 알립니다.

함수 열거(함수 0)

운영 체제가 플랫폼과 상호 작용하려면 ACPI 디바이스가 네임스페이스를 통해 노출되어야 합니다. 이 디바이스는 EISAID(“PNP0C0B”)를 포함하는 _CID 개체를 포함해야 합니다. 이 디바이스의 범위에는 디바이스가 지원하는 _DSM을 나타내는 다음 _DSM 정의가 포함되어야 합니다.

UUID	수정 버전	함수	설명
A7611840-99FE-41ae-A488-35C75926C8EB	0	0	함수 열거

Return: 위에 나열된 함수 0~3에 대한 지원을 나타내기 위해 함수 열거 함수(함수 0)는 0xF를 반환해야 합니다. 자세한 내용은 ACPI 사양의 섹션 9.1.1을 참조하세요.

팬 트립 포인트 지원 함수 가져오기(함수 1)

하드웨어는 OS에 RM 측면에서 지원되는 내용을 알려 줍니다.

UUID	수정 버전	함수	설명
A7611840-99FE-41ae-A488-35C75926C8EB	0	1	팬 트립 포인트 지원 가져오기

인수

Arg0: UUID: A7611840-99FE-41ae-A488- 35C75926C8EB

Arg1: 수정: 0

Arg2: 함수: 1

Arg3: 비어 있는 패키지

Return: 팬 트립 포인트에 지원되는 세분성을 포함하는 정수 값(RPM)입니다. 0이 아닌 경우 OS는 알림 세분성의 배수인 트립 포인트를 선택할 수 있습니다. 예를 들어 세분성이 200인 경우 OSPM은 0, 200, 400, 600 등의 RPM에서 트립 포인트를 선택할 수 있습니다. 값 0은 트립 포인트가 지원되지 않음을 나타냅니다.

팬 트립 포인트 함수 설정(함수 2)

OS는 다음 알림 트립 포인트가 무엇인지 하드웨어와 통신합니다. 하드웨어는 그런 일이 발생하면 OS에 알립니다.

UUID	수정 버전	함수	설명
A7611840-99FE-41ae-A488-35C75926C8EB	0	2	팬 트립 포인트 가져오기

인수

Arg0: UUID: A7611840-99FE-41ae-A488-35C75926C8EB

Arg1: 수정: 0

Arg2: 함수: 2

Arg3: 하한 및 상한 트립 포인트가 포함된 패키지입니다. (2개 요소 정수. 인덱스 0에서 하위, 인덱스 1에서 상위)

OSPM은 함수 1에 지정된 트립 포인트 세분성의 배수인 트립 포인트만 선택합니다. 팬의 실제 속도가 상위/하위 트립 포인트보다 높거나 낮아지면 플랫폼은 팬 디바이스에서 Notify(0x80)를 발급해야 합니다. 그런 다음 OSPM은 _FST(팬 상태)를 평가하여 현재 팬 속도를 확인합니다. 트립 포인트가 설정될 때 팬 속도가 이미 설정된 트립 포인트 외부에 있는 경우 플랫폼은 즉시 Notify(0x80)를 발급해야 합니다.

상위 트립 포인트는 세분성의 배수가 됩니다. 하위 트립 포인트는 (세분성의 배수) + 1 (하위 트립 포인트 < 상위 트립 포인트)입니다. RPM이 0이면 OS는 하위 트립 포인트를 0으로, 상위 트립 포인트를 1로 설정합니다.

Return: 없음.

팬 작동 범위 함수 가져오기(함수 3)

RPM 간 매핑 –> 영향. 단 하나의 팬(SoC에 가장 가까운 팬)만이 이 인터페이스를 구현할 수 있으며 ACPI 사양의 섹션 9.1.1에 있는 3개의 함수와 함수 0을 모두 구현해야 합니다.

UUID	수정 버전	함수	설명
A7611840-99FE-41ae-A488-35C75926C8EB	0	3	팬 운영 범위 가져오기

인수

Arg0: UUID: A7611840-99FE-41ae-A488-35C75926C8EB

Arg1: 수정: 0

Arg2: 함수: 3

Arg3: 비어 있는 패키지

Return: 다음 형식을 포함하는 패키지:

Package () {
	Impact1MaxRPM,		// Integer (DWORD)
	Impact2MaxRPM, 		// Integer (DWORD)
	Impact3MaxRPM, 		// Integer (DWORD)
	MaxRPM				// Integer (DWORD)
}

필드	형식	설명
Impact1MaxRPM	정수(DWORD)	팬 영향 범위 1에 대한 최대 RPM입니다.
Impact2MaxRPM	정수(DWORD)	팬 영향 범위 2에 대한 최대 RPM입니다. Impact1MaxRPM 이상이어야 합니다.
Impact3MaxRPM	정수(DWORD)	팬 영향 범위 3에 대한 최대 RPM입니다. Impact2MaxRPM 이상이어야 합니다.
MaxRPM	정수(DWORD)	팬이 작동할 수 있는 최대 RPM입니다. Impact3MaxRPM 이상이어야 합니다.

이 테이블은 각 팬 영향 수준에 대한 RPM 범위를 유도하는 데 사용됩니다.

영향 점수	하위 RPM 값	상위 RPM 값
1	1	Impact1MaxRPM
2	Impact1MaxRPM + 1	Impact2MaxRPM.
3	Impact2MaxRPM + 1	Impact3MaxRPM
4	Impact3MaxRPM + 1	MaxRPM

플랫폼에서 영향 범위를 사용하지 않는 경우(예: 팬이 영향 범위 2에서 영향 범위 4로 직접 전환하는 경우) 사용되지 않는 영향 범위의 최대 RPM을 낮은 영향 범위의 최대 RPM과 동일하게 설정하여 이를 나타낼 수 있습니다.

예제 매핑

OS로 전송된 값	팬 RPM	사용자 환경	RPM 최댓값
0 – 낮음	1~4000 RPM(<=25dBA)	팬이 켜지지 않거나 낮은 소음으로 켜짐	Impact1MaxRPM = 4000
1 – 중간	4001~5000RPM(25~30dBA)	중간 정도의 소음으로 팬 켜짐	Impact2MaxRPM = 5000
2 - 중간~높음	5001~6000RPM(30~36dBA)	중간~높은 정도의 소음으로 팬 켜짐	Impact3MaxRPM = 6000
3 = 높음	6001+RPM(36+dBA)	높은 소음으로 팬 켜짐	MaxRPM = 9000

예제 ASL 코드

    ...
 
    // _DSM - Device Specific Method
    // Arg0: UUID Unique function identifier
    // Arg1: Integer Revision Level
    // Arg2: Integer Function Index (0 = Return Supported Functions)
    // Arg3: Package Parameters
    Method(_DSM, 0x4, NotSerialized) {
            If(LEqual(Arg0, ToUUID("A7611840-99FE-41ae-A488-35C75926C8EB"))) {
                Switch (ToInteger(Arg2)) {
                    Case(0) {
                        // _DSM functions 0 through 3 are supported
                        Return (Buffer() {0xf})
                    }
                    Case(1) {
                        // Report 200 RPM granularity for trip points
                        Return (\_SB.FAN0.GRAN)
                    }
                    Case(2) {
                        // Save lower RPM trip point
                        Store(DeRefOf(Index(Arg3, 0)), \_SB.FAN0.LRPM)
                        // Save upper RPM trip point
                        Store(DeRefOf(Index(Arg3, 1)), \_SB.FAN0.URPM)
                        // Configure hardware for the trip points, Tell EC to set fan speed trip point.
                        \_SB.FAN0.CRNF()
                        Return (0)
                    }
                    Case(3) {
                        Return (Package(4) { 
                            4000, // 1-4000 RPM is impact score 1
                            5000, // 4001-5000 RPM is impact score 2
                            6000, // 5001-6000 RPM is impact score 3
                            9000})// 6001-9000 RPM is impact score 4
                    }
                    Default {
                        Return(Buffer(One) { 0x00 }) // Guid mismatch
                    }
                }
            }
            Else {
                Return(Buffer(One) { 0x00 }) // Guid mismatch
            }
    }  
 
} // end of FAN0
}

테스트 및 추적

로그를 수집하고 WPA(Windows 성능 분석기)에서 보려면 다음 단계를 참조하세요.

1. 설정 -> Windows 검색 -> 고급 검색 인덱서 설정 -> 고급 -> 인덱스 삭제 및 다시 빌드(다시 빌드)
2. wpr -boottrace -addboot AcpiFanNoiseImpact.wprp –filemode
3. 시스템 다시 시작
4. 설정의 인덱스 상태 확인 -> Windows 검색(디바이스가 AC 전원으로 연결되었는지 확인합니다.)
5. 인덱스가 완료되면 추적을 중지합니다. wpr -boottrace -stopboot AcpiFanNoiseImpact.etl(저장하지 않고 추적 취소: wpr -boottrace –cancel)
6. WPA(Windows 성능 분석기)를 통해 AcpiFanNoiseImpact.etl을 엽니다.

AcpiFanNoiseImpact.zip에서 파일을 다운로드하거나 다음을 복사하여 AcpiFanNoiseImpact.wprp로 저장합니다.

<?xml version="1.0" encoding="utf-8"?>
<WindowsPerformanceRecorder Version="1.0" Comments="Test" Company="Microsoft Corporation" Copyright="Microsoft Corporation">
    <Profiles>
        <!-- BufferSizes are in KB in WPRP -->
        <!-- System Collectors -->
        <SystemCollector Id="MySystemCollector" Name="NT Kernel Logger">
            <BufferSize Value="1024" />
            <Buffers Value="100" />
            <StackCaching BucketCount="2048" CacheSize="20480" />
            <FlushThreshold Value="70" />
        </SystemCollector>

        <!-- Event Collectors -->
        <EventCollector Id="MyEventCollector" Name="User Session Logger">
            <BufferSize Value="1024" />
            <Buffers Value="100" />
            <StackCaching BucketCount="2048" CacheSize="20480" />
            <FlushThreshold Value="70" />
        </EventCollector>

        <!-- System Providers for collecting kernel events. -->
        <SystemProvider Id="SP_AcpiFanNoiseImpactTrace">
            <Keywords Operation="Add">
                <Keyword Value="Loader" />
                <Keyword Value="Power" />
                <Keyword Value="ProcessThread" />
            </Keywords>
        </SystemProvider>
        <!-- System Providers for collecting kernel events. -->
        <!---->

        <EventProvider Id="EP_Microsoft-Windows-Kernel-Power" Name="Microsoft-Windows-Kernel-Power" Level="5" NonPagedMemory="true">
            <Keywords>
                <Keyword Value="0x2" />
            </Keywords>
            <CaptureStateOnStart>
                <Keyword Value="0x0" />
            </CaptureStateOnStart>
            <CaptureStateOnSave>
                <Keyword Value="0x0" />
            </CaptureStateOnSave>
        </EventProvider>
        <EventProvider Id="EP_Microsoft-Windows-Kernel-Acpi" Name="Microsoft-Windows-Kernel-Acpi" Level="5">
            <Keywords>
                <Keyword Value="0xffffffff" />
            </Keywords>
            <CaptureStateOnSave>
                <Keyword Value="0xffffffff" />
            </CaptureStateOnSave>
        </EventProvider>
        <EventProvider Id="CustomEventProvider_Microsoft.Windows.SRUM.Telemetry_TraceLogging" Name="7073707A-0587-4E03-B31F-6443EB1ACBCD" Level="5" />
        <EventProvider Id="CustomEventProvider_Microsoft.Windows.Kernel.Acpi_TraceLogging" Name="C42BBFDB-4140-4ada-81DF-2B9A18AC6A7B" Level="5" />
        <EventProvider Id="CustomEventProvider_Microsoft.Windows.Kernel.Power_TraceLogging" Name="63bca7a1-77ec-4ea7-95d0-98d3f0c0ebf7" Level="5" />
        <EventProvider Id="CustomEventProvider_AcpiTraceGuid_WPP" Name="03906A40-CCE8-447F-83F4-E2346215DB84" Level="7" />
        <EventProvider Id="CustomEventProvider_Microsoft.Windows.CentralResourceManager_TraceLogging" Name="8215e965-d26e-548e-af0e-940c1f06f250" Level="5" NonPagedMemory="true">
            <CaptureStateOnSave>
                <Keyword Value="0xFFFFFFFFFFFFFFFF" />
            </CaptureStateOnSave>
        </EventProvider>

        <Profile Id="PowerTrace.Verbose.File" LoggingMode="File" Name="PowerTrace" DetailLevel="Verbose" Description="Power trace logging">
            <Collectors>
                <SystemCollectorId Value="MySystemCollector">
                    <SystemProviderId Value="SP_AcpiFanNoiseImpactTrace" />
                </SystemCollectorId>
                <EventCollectorId Value="MyEventCollector">
                    <EventProviders>
                        <EventProviderId Value="EP_Microsoft-Windows-Kernel-Power" />
                        <EventProviderId Value="EP_Microsoft-Windows-Kernel-Acpi" />
                        <EventProviderId Value="CustomEventProvider_Microsoft.Windows.Kernel.Acpi_TraceLogging" />
                        <EventProviderId Value="CustomEventProvider_AcpiTraceGuid_WPP" />
                        <EventProviderId Value="CustomEventProvider_Microsoft.Windows.Kernel.Power_TraceLogging" />
                        <EventProviderId Value="CustomEventProvider_Microsoft.Windows.SRUM.Telemetry_TraceLogging" />
                        <EventProviderId Value="CustomEventProvider_Microsoft.Windows.CentralResourceManager_TraceLogging" />
                    </EventProviders>
                </EventCollectorId>
            </Collectors>
        </Profile>
    </Profiles>
    <TraceMergeProperties>
        <TraceMergeProperty Id="TraceMerge_Default" Name="TraceMerge_Default" Base="">
            <DeletePreMergedTraceFiles Value="true" />
            <FileCompression Value="true" />
            <CustomEvents>
                <CustomEvent Value="ImageId" />
                <CustomEvent Value="BuildInfo" />
                <CustomEvent Value="VolumeMapping" />
                <CustomEvent Value="EventMetadata" />
                <CustomEvent Value="PerfTrackMetadata" />
                <CustomEvent Value="WinSAT" />
                <CustomEvent Value="NetworkInterface" />
            </CustomEvents>
        </TraceMergeProperty>
    </TraceMergeProperties>
</WindowsPerformanceRecorder>

아래 이미지는 팬이 시끄러울 때 검색 인덱서 작업이 중단되는 것을 보여 주는 WPA 그래프의 예입니다.

검색 인덱스를 완전히 중단할 수 있는 팬 수준은 한 단계(가장 높은 수준, 영향 점수 4)이지만 다른 모든 팬 수준은 일시 중지가 아닌 활동 감소여야 합니다. 예를 들어 ACPI가 함수 3(팬 작동 범위 가져오기 함수)에서 Impact3MaxRPM = 4000RPM을 선언한 경우 팬 RPM >이 4000(4100RPM, 4500RPM)이면 SearchIndexer.exe 및 SearchProtocalHost.exe CPU 사용이 일시 중지됩니다.

참고

CPU 사용량을 보려면 wpr -start power -filemode를 사용하여 런타임 사용량을 수집할 수 있습니다. wpr -stop fan_noise.etl을 사용하여 로그 수집을 중지합니다.

아래 이미지는 SearchIndexer.exe 및 SearchProtocolHost의 일시 중지를 보여 주는 WPA 그래프의 예를 보여 줍니다.