이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license.).
리눅스(tm) 커널 내의 CPU 핫플러그 지원
메인테이너:
CPU 핫플러그 코어:
Rusty Russell <rusty@rustcorp.com.au>
Srivatsa Vaddagiri <vatsa@in.ibm.com>
i386:
Zwane Mwaikambo <zwane@arm.linux.org.uk>
ppc64:
Nathan Lynch <nathanl@austin.ibm.com>
Joel Schopp <jschopp@austin.ibm.com>
ia64/x86_64:
Ashok Raj <ashok.raj@intel.com>
s390:
Heiko Carstens <heiko.carstens@de.ibm.com>
저자: Ashok Raj <ashok.raj@intel.com>
많은 피드백: Nathan Lynch <nathanl@austin.ibm.com>,
Joel Schopp <jschopp@austin.ibm.com>
번역: 양정석 <dasomoli@gmailREMOVETHIS.com>
소개
시스템 아키턱처 내의 현대 발달은 고급 에러 리포팅과 프로세서 내의 교정 능력을
도입하였습니다. CPU 아키텍처들은 하나의 CPU의 계산 자원을 가상 머신 환경이
이용 가능하도록 파티셔닝을 지원합니다. 물리적 노드 추가와 제거가 CPU 핫플러그
지원이 필요한 곳에서는 핫 플러그가 잘 되는 NUMA 하드웨어를 지원하는 몇몇의
OEM들이 있습니다.
이러한 발달은 커널에게 공급 이유들이나 RAS 목적들 중 하나를 위해 시스템 실행
경로를 차단하는데 대한 문제를 막기 위해서 CPU들이 제거될 수 있어야 함을 필요로
합니다. 그래서 리눅스 커널 내에 CPU 핫플러그 지원이 필요합니다.
더 새로운 CPU-핫플러그 지원의 용도는 오늘날에 SMP 를 위한 suspend resume 지원
내의 그 사용입니다. 듀얼 코어와 HT 지원은 랩탑조차 이런 방법을 지원하지 않는
SMP 커널을 실행하도록 만들었습니다. suspend/resume을 위한 SMP 지원은 계속
진행되고 있습니다.
CPU 핫플러그에 대한 일반적인 사항
———————————
커맨드 라인 스위치
——————
maxcpus=n 부팅 타임 CPU를 n으로 제한함. 여러분이 4 CPU를 가지고 있을 때,
maxcpus=2를 사용하면 2개만 부팅합니다. 다른 CPU들은 나중에 온라인
상태로 가져오도록 선택할 수 있습니다. 더 많은 정보는 FAQ를
읽어보세요.
additional_cpus=n (*) 핫플러그 가능한 CPU들을 제한하는데 사용. 이 옵션은
cpu_possible_mask = cpu_present_mask + additional_cpus
를 셋팅합니다.
cede_offline={“off”,”on”} 이 옵션은 오프라인된 프로세서를 확장 H_CEDE 상태로
두는 것을 이를 지원하는 p시리즈 플랫폼 상에서
끄고/켜는데 사용됩니다.
만약 이 옵션이 지정되지 않으면, cede_offline은 “on”
으로 셋팅됩니다.
(*) 다음 아키텍처에서만 옵션이 유효
– ia64
ia64 는 잠재적으로 핫플러그될 수 있는 CPU의 숫자를 결정하기 위해서 ACPI 테이블
MADT 안의 꺼진 로컬 apics의 숫자를 사용합니다. 그 구현은 오직 CPU의 개수를
세는데만 의존적이지만 *반드시* 꺼진 apics를 위한 이들 테이블의 apicid 값에
의존하지는 않습니다. BIOS 가 이들 핫플러그 가능한 CPU를 꺼진 항목으로 표시하지
않는 상황에서는, cpu_possible_mask 안의 이들 CPU를 나타내기 위해서 누군가
이 파라미터 “additional_cpus=x”를 사용할 수 있습니다.
possible_cpus=n [s390,x86_64] 핫플러그 가능한 CPU를 셋팅하기 위해 이것을
사용합니다. 이 옵션은 cpu_possible_mask 안의 possible_cpus
비트들을 셋팅합니다. 그래서 비트의 수를 유지하는 것은
그 머신이 재부팅된다 하더라도 변하지 않습니다.
CPU 맵들과 그 들
—————-
[cpumaps 상의 더 많은 것과 조작을 위한 기본적인 것들은 더 자세한 글을 가진
include/linux/cpumask.h를 확인해 보세요.]
cpu_possible_mask: 시스템 내에서 이용 가능할 수 있는 가능한 CPU들의 비트맵.
이 것은 어떤 부팅 타임 메모리를 CPU들을 사용 가능하게 만들거나 제거되는 것과
같이 늘어나거나/줄어들지 않는 것으로 설계되지 않은 per_cpu 변수로 할당하는데
사용됩니다. 부팅 타임 탐색 단계에서 셋팅되고 나면 그 맵은 변하지 않습니다.
즉, 어느 시점의 비트의 추가나 제거가 되지 않습니다. 여러분의 시스템의 다가올
수요를 위해 정확하게 그것을 다듬는 것은 부팅 타임 메모리를 절약할 수 있습니다.
어떻게 우리가 x86_64 경우에 이 것의 하한 검사를 막기 위해 휴리스틱을 사용하는
지 아래에서 보세요.
cpu_online_mask: 현재 온라인인 모든 CPU들의 비트맵. 한 CPU가 커널 스케줄링과
디바이스들로부터 인터럽트를 받을 수 있도록 하는 준비가 이용가능해진 이후에
__cpu_up() 내에서 그 셋팅이 됩니다. 한 CPU가 인터럽트를 다른 목표하는 CPU로
옮겨놓는 것을 포함하는 모든 OS 서비스 전에 __cpu_disable()을 사용해서
꺼질 때, 클리어 됩니다.
cpu_present_mask: 시스템 내에 현제 존재하는 CPU들의 비트맵. 그들 모두가
온라인이지는 않습니다. 물리적 핫플러그가 처리될 때 관련된 서브 시스템
(예로, ACPI)이 바꾸거나 새로운 비트가 그 이벤트가 핫-추가/핫-제거임에
따라 관련된 맵으로부터 추가 또는 제거됩니다. 지금은 현재 락킹 규칙이 없습니다.
일반적인 사용은 핫플러그가 꺼진 시간인 부팅 동안 토폴리지를 초기화하는
것입니다.
여러분은 그 시스템 CPU 맵들의 어떤 조작이 정말로 필요하지는 않습니다. 그들은
대부분의 용도를 위해 읽기-전용이 되어야 합니다. per-cpu 자원을 셋팅할 때 거의
어느때나 cpu_possible_mask/(반복을 위해)for_each_possible_cpu() 를 사용하세요.
CPU들의 비트맵을 표현하기 위해 cpumask_t 말고 절대 어떤 다른 것을 사용하지 마세요.
#include <linux/cpumask.h>
for_each_possible_cpu – cpu_possible_mask 상의 반복
for_each_online_cpu – cpu_online_mask 상의 반복
for_each_present_cpu – cpu_present_mask 상의 반복
for_each_cpu_mask(x,mask) – CPU mask의 어떤 무작위 모음 상의 반복
#include <linux/cpu.h>
get_online_cpus() 와 put_online_cpus():
위의 호출들은 CPU 핫플러그 연산을 금하기 위해 사용됩니다. cpu_hotplug.refcount
가 0이 아닌 동안, cpu_online_mask는 바뀌지 않을 것입니다. 만약 여러분이
드물게 CPU들이 없어지는 것을 막을 필요가 있다면, 여러분은 또한
preempt_disable() 과 preempt_enable()을 그 부분에서 사용할 수 있습니다.
크리티컬 섹션은 이 프로세스를 떠나 슬립되거나 스케줄링될 수 있는 함수를 부를
수 없다는 것을 기억하세요. preempt_disable()은 CPU를 끄기 위해 사용되는
stop_machine_run() 이 사용되는 시간만큼 동작할 것입니다.
CPU 핫플러그 – 자주 묻는 질문과 답변(FAQ)
Q: 어떻게 내 커널이 CPU 핫플러그를 지원하도록 할 수 있나요?
A: make defconfig할 때, CPU 핫플러그 지원을 켜세요.
“Processor type and Features” -> Support for Hotpluggable CPUs
여러분이 CONFIG_SMP 를 잘 켜놨는지 확인하시고요.
여러분은 SMP suspend/resume이 잘 지원되도록 CONFIG_HOTPLUG_CPU를 켤 필요가
있을 겁니다.
Q: 어떤 아키텍처가 CPU 핫플러그를 지원하나요?
A: 2.6.14에서, 다음 아키텍처가 CPU 핫플러그를 지원합니다.
i386 (인텔), ppc, ppc64, parisc, s390, ia64 그리고 x86_64
Q: 새로 빌드된 커널 상에서 핫플러그가 지원되는지 어떻게 테스트할 수 있나요?
A: sysfs 상의 한 항목이 현재 있어야 합니다.
“mount” 명령을 사용해서, sysfs 가 마운트되었는지 확인하세요. 여러분은
그 출력 안에 아래에서 보이는 것 같은 항목이 보여야 합니다.
….
none on /sys type sysfs (rw)
….
마운트 되어 있지 않다면, 다음을 실행하세요.
#mkdir /sysfs
#mount -t sysfs sys /sys
그러면 모든 존재하는 CPU를 위한 항목들이 보여야 합니다. 다음은 8-way 시스템
내의 예제입니다.
#pwd
#/sys/devices/system/cpu
#ls -l
total 0
drwxr-xr-x 10 root root 0 Sep 19 07:44 .
drwxr-xr-x 13 root root 0 Sep 19 07:45 ..
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu0
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu1
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu2
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu3
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu4
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu5
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu6
drwxr-xr-x 3 root root 0 Sep 19 07:48 cpu7
각 디렉토리 아래에서 여러분은 프로세서를 논리적으로 온라인/오프라인 상태로
제어하는 파일인 “online” 파일을 찾을 수 있을 겁니다.
Q: 핫-추가/핫-제거가 CPU들의 물리적인 추가/제거를 참조하나요?
A: 핫-추가/제거의 사용은 코드 안에서 매우 일관적이지 않습니다.
CONFIG_HOTPLUG_CPU는 커널 내에서 논리적인 온라인/오프라인 능력을 켭니다.
물리적인 추가/제거를 지원하기 위해서는, 어떤 BIOS 훅들이 필요하고, 플랫폼은
PCI 핫플러그 내에 차렷 버튼 같은 어떤 것을 가지고 있어야 할 겁니다.
CONFIG_ACPI_HOTPLUG_CPU 는 CPU들의 물리적인 추가/제거를 위한 ACPI 지원을
켭니다.
Q: 한 CPU를 논리적으로 오프라인시키려면 어떻게 해야 하나요?
A: 다음을 수행하세요.
#echo 0 > /sys/devices/system/cpu/cpuX/online
논리적 오프라인이 성공하고나면, 다음을 검사하세요
#cat /proc/interrupts
여러분은 제거된 CPU를 이제부터 볼 수 없어야 합니다. 또한 온라인 파일은
CPU가 오프라인일 때는 그 상태를 0으로, 온라인일 때는 1로 보고할 겁니다.
#현재 CPU 상태를 보이기 위해서.
#cat /sys/devices/system/cpu/cpuX/online
Q: 어떤 시스템 상에서는 왜 CPU0를 제거할 수 없나요?
A: 어떤 아키텍처는 어떤 CPU상에서는 어떤 특별한 의존성을 가지고 있습니다.
IA64 플랫폼을 예로 들자면, 우리는 교정된 플랫폼 에러 인터럽트 (Corrected
Platform Error Interrupts:CPEI)로 알려진 플랫폼 인터럽트를 OS로 보낼 수 있는
능력이 있습니다. 그 목표하는 CPU를 바꾸는 방법은 없습니다. 그래서 현재 ACPI
버전이 리다이렉션 같은 것을 지원하지 않으면, 우리는 제거 가능하지 않게
만듦으로써 그 CPU를 끕니다.
이런 경우에는 여러분은 그 온라인 파일이 cpu0 아래에 없는 것을 볼 수 있을 겁니다.
Q: X86 상에서는 CPU0가 제거 가능한가요?
A: 네. 커널이 CONFIG_BOOTPARAM_HOTPLUG_CPU0=y로 컴파일되었다면, CPU0 는
기본값으로 제거가능합니다. 아니면, CPU0 는 커널 옵션 cpu0_hotplug 로 또한
제거가능합니다.
그러나 CPU0에 의존하는 어떤 기능이 있습니다. 두가지 알려진 의존은:
1. CPU0 상에 의존하는 하이버네이션/suspend 로부터의 resume. 하이버네이션/suspend
는 CPU0가 오프라인이면 실패할 것이고, 하이버네이션/suspend 가 계속되기 전에
CPU0를 온라인시킬 필요가 있습니다.
2. CPU0에 또한 의존하는 PIC 인터럽트들. CPU0는 PIC 인터럽트가 검출되면 제거될
수 없습니다.
그것은 내가 어떤 몇 개의 테스팅된 머신 상에서는 CPU0가 offline 이 된 후에 어떤
전원 끄기/재부팅 실패를 보지 못했더라도 어떤 머신 상에서는 전원 끄기/재부팅이
CPU0 에 의존할 것임을 말합니다.
CPU0의 다른 어떤 의존을 보거나 알게된다면 알려주세요.
그 의존이 여러분의 제어 아래에 있다면, 여러분은 CPU0 핫플러그 기능을
CONFIG_BOOTPARAM_HOTPLUG_CPU0 나 커널 파라미터 cpu0_hotplug를 통해 켤 수
있습니다.
–Fenghua Yu <fenghua.yu@intel.com>
Q: 특정한 CPU가 제거 가능하지 않은지 어떻게 알아낼 수 있나요?
A: 구현에 따라, 어떤 아키텍처는 이 것을 “online” 파일을 없앰으로써 보여주기도
합니다. 이 CPU 가 제거될 수 없는 시간보다 먼저 결정될 수 있다면 가능합니다.
어떤 상황에서는 이것은 런타임 검사가 될 수 있습니다. 즉, 여러분이 마지막 CPU를
제거하려고 하면, 이 동작은 거부될 것입니다. 여러분은 “echo” 명령의 반환 값을
조사함으로써 이런 실패를 찾을 수 있습니다.
Q: CPU가 논리적으로 오프라인되고 있을 때는 무슨 일이 일어나나요?
A: 특정 순서 없이 나열된 다음 일들이 일어납니다. 🙂
– 커널내부에 등록된 모듈들로 suspend 동작으로 인해 작업들이 멈춰지는 동안에
그 CPU 가 오프라인 되고 있는지, 아닌지에 따라 CPU_DOWN_PREPARE 또는
CPU_DOWN_PREPARE_FROZEN 이벤트를 보냄으로써 알려집니다.
– 모든 프로세스들이 이 없어지는 CPU에서 새로운 CPU들로 이전됩니다.
새로운 CPU는 각 프로세스의 모든 온라인 CPU의 부분 집합이 될 현재 cpuset
으로부터 선택됩니다.
– 이 CPU로 오던 모든 인터럽트들은 새로운 CPU로 이전됩니다.
– 타이머/보톰하프/태스크릿들 역시 새로운 CPU로 이전됩니다.
– 모든 서비스가 이전되고 나면, 커널은 아키텍처 종속적인 클린업을 수행하기 위해서
아키텍처 종속적 루틴인 __cpu_disable() 을 호출합니다.
– Once this is successful, an event for successful cleanup is sent by an event
CPU_DEAD (or CPU_DEAD_FROZEN if tasks are frozen due to a suspend while the
CPU is being offlined).
– 이 것이 성공하고 나면, 성공적인 클린업을 알리는 이벤트가 CPU_DEAD (또는
태스크가 CPU가 오프라인이 되는 동안 suspend로 인해 멈춘다면 CPU_DEAD_FROZEN)
을 보내집니다.
“이것은 각 서비스가 CPU_DOWN_PREPARE 노티파이어가 호출되었을 때 클린업되었다고
여겨집니다. CPU_DEAD가 호출되었을 때 그것은 오프라인 되었을 이 CPU 상에
실행되는 것이 없을 것으로 여겨집니다.”
Q: CPU 도착과 출발을 알 수 있는 어떤 커널 코드는 가지고 있다면 어떻게 적절히
알려주기 위해 조정해야 하나요?
A: 이것은 여러분이 여러분의 커널 코드 안에 알림을 받기 위해 필요할 그 무엇입니다.
#include <linux/cpu.h>
static int foobar_cpu_callback(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
unsigned int cpu = (unsigned long)hcpu;
switch (action) {
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
foobar_online_action(cpu);
break;
case CPU_DEAD:
case CPU_DEAD_FROZEN:
foobar_dead_action(cpu);
break;
}
return NOTIFY_OK;
}
static struct notifier_block foobar_cpu_notifer =
{
.notifier_call = foobar_cpu_callback,
};
여러분은 여러분의 init 함수로부터 register_cpu_notifier()를 호출할 필요가
있습니다. Init 함수는 두가지 종류가 될 수 있습니다:
1. early init (부트 프로세서가 온라인일 때만 호출되는 init 함수)
2. late init (모든 CPU가 온라인이 된 _후에_ 호출되는 init 함수)
첫번째 경우를 위해, 여러분은 다음을 여러분의 init 함수에 추가해야 합니다.
register_cpu_notifier(&foobar_cpu_notifier);
두번째 경우를 위해서, 여러분은 여러분의 init 함수에 다음을 추가해야 합니다.
register_hotcpu_notifier(&foobar_cpu_notifier);
여러분은 어떤 것이 자원을 준비하는데 동작하지 않으면 PREPARE 노티파이어를 실패할
수 있습니다. 이것은 그 동작을 멈추고 다음 CANCELED 이벤트를 다시 보낼 것입니다.
CPU_DEAD 는 그 좋지않은 징후만으로 실패되면 안됩니다. 그러나 경로 내의
노티파이어가 BAD 알림 코드를 보내면 나쁜 일들이 일어날 겁니다.
Q: 나는 모든 CPU가 모두 올라가고 실행되기 위해 호출하는 나의 동작들을 보지 않나요?
A: 네, CPU 노티파이어들은 새로운 CPU 들이 온라인되거나 오프라인될 때만 호출됩니다.
여러분이 그 시스템 내의 각 CPU에 대한 어떤 동작을 수행할 필요가 있다면,
for_each_online_cpu(i) {
foobar_cpu_callback(&foobar_cpu_notifier, CPU_UP_PREPARE, i);
foobar_cpu_callback(&foobar_cpu_notifier, CPU_ONLINE, i);
}
Q: 새로운 아키텍처를 위한 CPU 핫플러그 지원을 개발하고 싶다면, 최소한 무엇이
필요한가요?
A: 다음에 있는 것들이 정확히 동작하기 위해서 CPU 핫플러그 인프라스트럭쳐에
필요한 것들입니다.
– CONFIG_HOTPLUG_CPU가 Kconfig 내에 켜져 있는지 확인하세요.
– __cpu_up() – CPU를 켜기 위한 Arch 인터페이스
– __cpu_disable() – CPU를 끄기 위한 Arch 인터페이스, 이 루틴이 반환하고
난 후에는 더이상 인터럽트들이 커널에 의해서 처리될 수
없습니다. 로컬 APIC 타이머를 포함한 기타의 것들이
꺼집니다.
– __cpu_die() – 이것은 실제로 CPU가 죽은 것을 보장하기 위해 제공합니다.
CPU 핫플러그를 구현한 다른 아키텍처 내의 어떤 예제
코드를 실제로 보세요. 그 프로세서는 지정된 아키텍처를
위한 idle() 루프로부터 꺼집니다. __cpu_die()는
일반적으로 그 프로세서의 죽는 루틴이 분명히
호출되었음을 확인하기 위해서 셋팅되는 어떤 per_cpu
상태를 기다립니다.
Q: 이 CPU 로 지정된 어떤 일이 진행 중일 때, 특정 CPU가 제거되지 않음을 보장할
필요가 있습니다.
A: 두가지 방법이 있습니다. 여러분의 코드가 인터럽트 컨텍스트 내에서 실행될 수
있다면, smp_call_function_single() 을 사용하고, 아니라면 work_on_cpu() 를
사용하세요. work_on_cpu는 느리고, 메모리 부족으로 실패할 수 있음을
알아두시고요:
int my_func_on_cpu(int cpu)
{
int err;
get_online_cpus();
if (!cpu_online(cpu))
err = -EINVAL;
else
#if NEEDS_BLOCKING
err = work_on_cpu(cpu, __my_func_on_cpu, NULL);
#else
smp_call_function_single(cpu, __my_func_on_cpu, &err,
true);
#endif
put_online_cpus();
return err;
}
Q: 핫플러그를 위해 얼마나 많은 CPU가 이용가능한지 어떻게 결정할 수 있나요?
A: 최근의 정보를 우리에게 줄 수 있는 ACPI 로부터 방법이 정의된 명확한 스펙은
없습니다. Unisys의 Natalie 로부터의 어떤 입력에 기초하여, ACPI MADT(Multiple
APIC Description Tables)는 시스템 내에 꺼진 상태로 있는 가능한 CPU들을
표시합니다.
Andi 는 핫플러그 가능한 CPU들로 MADT 안에서 꺼진 CPU들의 숫자를 세는 간단한
휴리스틱으로 구현했습니다. 꺼진 CPU가 없는 경우에는 핫플러그 가능한 현재
존재하는 CPU를 1/2 개수로 가정합니다.
경고: ACPI MADT 는 ACPI 2.0c 또는 그 이전의 ACPI 버전을 지원하는 시스템
안에서는 그 MADT 안의 apicd 필드가 8비트이기 때문에 256개의 항목만 지원할 수
있습니다. ACPI 3.0 이후부터 이 제한은 x2APIC가 소개되면서 apicid 필드가
32비트로 확장된 이후로 제거되었습니다.
유저 공간 알림
디바이스를 위한 핫플러그 지원은 리눅스 안에서 오늘날 일반적입니다. 그것은
네트워크, USB, 그리고 PCI 디바이스들의 자동 설정을 지원하는데 오늘날 사용되고
있습니다. 핫플러그 이벤트는 설정 태스크를 수행하기 위한 에이전트 스크립트를
호출하는데 사용될 수 있습니다.
여러분은 /etc/hotplug/cpu.agent 를 핫플러그 알림 유저 공간 스크립트를 처리하기
위해서 추가할 수 있습니다.
#!/bin/bash
# $Id: cpu.agent
# Kernel hotplug params include:
#ACTION=%s [online or offline]
#DEVPATH=%s
#
cd /etc/hotplug
. ./hotplug.functions
case $ACTION in
online)
echo `date` “:cpu.agent” add cpu >> /tmp/hotplug.txt
;;
offline)
echo `date` “:cpu.agent” remove cpu >>/tmp/hotplug.txt
;;
*)
debug_mesg CPU $ACTION event not supported
exit 1
;;
esac