[카테고리:] Development

[Linux:Kernel] worker thread 의 work function 확인

다솜돌이 Leave a comment

https://lkml.org/lkml/2011/3/31/68 를 참고하면 된다.

첫번째 방법은 다음을 실행한 후

$ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event

다음을 실행해서 trace 결과를 파일로 저장하는 것이다.

$ cat /sys/kernel/debug/tracing/trace_pipe > out.txt

파일로 저장하는 것은 android 에서 adb 를 이용한다면 다음과 같이 adb pull 로 /sys/kernel/debug/tracing/trace_pipe 를 가져오도록 해도 될 것이다.

adb pull /sys/kernel/debug/tracing/trace_pipe out.txt

두번째 방법은 해당 workqueue의 pid로 다음과 같이 얻어내는 것이다.

$ cat /proc/<pid>/stack

 

[Linux:Kernel] strncpy 대신 strlcpy

다솜돌이 Leave a comment

이 글에 있는 모든 코드는 GPL License를 따릅니다(All code attached is released under the GPL License in this article).

strncpy 에서는 source의 길이가 destination의 버퍼 길이와 같거나 더 길 경우, NUL-terminate되지 않는다. 구현이 다음과 같기 때문이다.

/**
 * strncpy – Copy a length-limited, %NUL-terminated string
 * @dest: Where to copy the string to
 * @src: Where to copy the string from
 * @count: The maximum number of bytes to copy
 *
 * The result is not %NUL-terminated if the source exceeds
 * @count bytes.
 *
 * In the case where the length of @src is less than  that  of
 * count, the remainder of @dest will be padded with %NUL.
 *
 */
char *strncpy(char *dest, const char *src, size_t count)
{
        char *tmp = dest;
        while (count) {
                if ((*tmp = *src) != 0)
                        src++;
                tmp++;
                count–;
        }
        return dest;
}

그래서 NUL-terminate를 보장하기 위한 함수가 있다 strlcpy 이다. 이 함수는 size-1 만큼의 string 복사와 함께 NULL로 끝남을 보장해 준다.

/**
 * strlcpy – Copy a %NUL terminated string into a sized buffer
 * @dest: Where to copy the string to
 * @src: Where to copy the string from
 * @size: size of destination buffer
 *
 * Compatible with *BSD: the result is always a valid
 * NUL-terminated string that fits in the buffer (unless,
 * of course, the buffer size is zero). It does not pad
 * out the result like strncpy() does.
 */
size_t strlcpy(char *dest, const char *src, size_t size)
{
        size_t ret = strlen(src);
        if (size) {
                size_t len = (ret >= size) ? size – 1 : ret;
                memcpy(dest, src, len);
                dest[len] = ‘\0’;
        }
        return ret;
}

strncpy를 strlcpy로 교체해야 할 것 같지만, 현재 커널에서는 둘 다 많이 사용되고 있다.
커널에서의 두 함수의 구현은 lib/string.c 에 있다.

참고 : http://lwn.net/Articles/33812/

[Linux:Kernel] 리눅스(tm) 커널 내의 CPU 핫플러그 지원

다솜돌이 Leave a comment

이 문서의 저작권은 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

[Linux:Kernel] cpufreq.c 안의 cpu_policy_rwsem 에 관련된 규칙

다솜돌이 Leave a comment

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

 cpu_policy_rwsem 은 락 이슈와 관련된 모든 cpufreq/핫플러그/워크 큐/기타를
 해결하기 위한 per CPU reader-writer 세마포어입니다.
 
 이 세마포어를 위한 규칙은 다음과 같습니다:
 – policy 구조체로부터 읽기를 원하는 어떤 루틴은 이 세마포어를 down_read해야
   할 것입니다.
 – policy 구조체로 쓸 것이고(또는) 함께 그 policy를 취해갈(예를 들면, CPU
   핫플러그) 어떤 루틴은 쓰기 전에 쓰기 모드에서 이 락을 잡아야 할 것입니다.
    
 추가적인 규칙:
 – 모든 이 락을 잡고 있는 자들은 그들이 락을 잡은 후에 그들이 신경쓰는 CPU가
   온라인임을 확인하기 위해 검사하여야 합니다.
 – cpufreq 핫플러그 패스에서 호출될 수 있는 가버너 루틴은 이를 취하는 최고 레벨
   핫플러그 노티파이어 핸들러로서 이 세마포어를 취하지 말아야 합니다.
 – __cpufreq_governor(data, CPUFREQ_GOV_STOP); 을 가로지르는 락은 잡지 말아야
   합니다

static DEFINE_PER_CPU(int, cpufreq_policy_cpu);
static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);

 

[Linux:Kernel] Linux CPUFreq User guide

다솜돌이 Leave a comment

이 문서의 저작권은 GPL을 따릅니다.(This document is released under the GPL license.)

            리눅스(TM) 커널 안의 CPU 주파수와 전압 조정 코드
                         L i n u x    C P U F r e q
                             U S E R   G U I D E
                    Dominik Brodowski  <linux@brodo.de>
                번역 : 양정석 <dasomoli@gmailREMOVETHIS.com>
   Clock scaling allows you to change the clock speed of the CPUs on the
    fly. This is a nice method to save battery power, because the lower
            the clock speed, the less power the CPU consumes.
차례:
—–
1. 지원되는 아키텍처와 프로세서들
1.1 ARM
1.2 x86
1.3 sparc64
1.4 ppc
1.5 SuperH
1.6 Blackfin
2. “정책” / “가버너”?
2.1 정책
2.2 가버너
3. CPU cpufreq 정책과(또는) 속도를 어떻게 바꾸는지
3.1 선호되는 인터페이스: sysfs
1. 지원되는 아키텍처와 프로세서들
=================================
1.1 ARM
——-
다음의 ARM 프로세서들이 cpufreq 에 의해 지원됩니다:
ARM Integrator
ARM-SA1100
ARM-SA1110
Intel PXA
1.2 x86
——-
다음의 x86 아키텍처의 프로세서들이 cpufreq 에 의해 지원됩니다:
AMD Elan – SC400, SC410
AMD mobile K6-2+
AMD mobile K6-3+
AMD mobile Duron
AMD mobile Athlon
AMD Opteron
AMD Athlon 64
Cyrix Media GXm
Intel mobile PIII 와 확실한 칩셋 상의 Intel mobile PIII-M
Intel Pentium 4, Intel Xeon
Intel Pentium M (Centrino)
National Semiconductors Geode GX
Transmeta Crusoe
Transmeta Efficeon
VIA Cyrix 3 / C3
ACPI 2.0 호환 시스템 상의 다양한 프로세서들 [*]
[*] “ACPI 프로세서 성능 상태” 들이 ACPI<->BIOS 인터페이스로 이용
가능한 경우만.
1.3 sparc64
———–
다음의 sparc64 아키텍처의 프로세서들이 cpufreq 에 의해 지원됩니다:
UltraSPARC-III
1.4 ppc
——-
여러 “PowerBook” 과 “iBook2” 노트북들이 지원됩니다.
1.5 SuperH
———-
클럭 프레임워크를 통해 속도 반올림을 지원하는 모든 SuperH 프로세서가 
cpufreq 에 의해 지원됩니다.
1.6 Blackfin
————
다음의 Blackfin 프로세서들이 cpufreq 에 의해 지원됩니다:
BF522, BF523, BF524, BF525, BF526, BF527, Rev 0.1 또는 그 이상
BF531, BF532, BF533, Rev 0.3 또는 그 이상
BF534, BF536, BF537, Rev 0.2 또는 그 이상
BF561, Rev 0.3 또는 그 이상
BF542, BF544, BF547, BF548, BF549, Rev 0.1 또는 그 이상
2. “정책” / “가버너” ?
======================
몇몇 CPU 주파수 조정-가능 프로세서는 다양한 주파수들과 동작 전압 사이를
“실행 중에” 어떤 커널이나 사용자 간섭없이 변환합니다. 이것은 사용자가
필요로 하는 것을 해주기에 충분히 높은, 그러나 전력을 절약하기에 충분한
주파수로의 매우 빠른 변환을 보장합니다.
2.1 정책
——–
이들 시스템 상에서, 여러분이 할 수 있는 모든 것은 여러분이 더 공격적인
전력-절약을 원하는만큼 또는 더 즉각적인 처리 능력을 원하는지에 맞춰
높고 낮은 주파수 제한 사항을 선택하는 것입니다.
2.2 가버너
———-
모든 다른 cpufreq 구현 상에서, 이들 경계는 여전이 셋팅될 필요가 있습니다.
그럼 “가버너”가 반드시 선택되어야 합니다. 앞서 언급한 “가버너”는 프로세서가
어떤 속도를 경계안에서 사용할 것인지를 결정합니다. 이런 “가버너”는
“사용자공간” 가버너입니다. 이것은 사용자 – 또는 아직 구현되지 않은
사용자공간 프로그램이 그 프로세서가 어떤 지정된 속도로 실행할지를
결정하도록 할 수 있습니다.
3. CPU cpufreq 정책과(또는) 속도를 어떻게 바꾸는지
==================================================
3.1 선호되는 인터페이스: sysfs
——————————
선호되는 인터페이스는 sysfs 파일시스템 안에 위치합니다. 여러분이
/sys에 그것을 마운트하였다면, cpufreq 인터페이스는 cpu-device 디렉토리
안의 그 하위 디렉토리 “cpufreq” 에 위치합니다
(예를 들면, 첫번째 CPU를 위해 /sys/devices/system/cpu/cpu0/cpufreq).
cpuinfo_min_freq :              이 파일은 그 프로세서가 실행할 수 있는 최하
                                동작 주파수(hKz)를 보여줍니다.
cpuinfo_max_freq :              이 파일은 그 프로세서가 실행할 수 있는 최고
                                동작 주파수(kHZ)를 보여줍니다.
cpuinfo_transition_latency      이 CPU 상에서 두 주파수 사이에 변환되는데
                                걸리는 나노초 시간. 알려져 있지 않거나,
                                ondemand 가버너로 그 드라이버가 동작하지
                                않는 높은 값으로 알려지면, -1
                                (CPUFREQ_ETERNAL) 이 반환될 것입니다.
                                이 정보를 사용하는 것은 커널 가버너나
                                사용자공간 대몬을 위한 주파수의 폴링을
                                선택하는데 유용합니다. 성능 저하 상 너무
                                잦은 결과치 산출로 주파수를 변환하지 않도록
                                하세요.
                                
scaling_driver :                이 파일은 이 CPU 상의 주파수를 셋팅하는데
                                무슨 cpufreq 드라이버가 사용되는지 보여줍니다.
scaling_available_governors :   이 파일은 이 커널 안의 사용가능한 CPUfreq
                                가버너들을 보여줍니다. 여러분은 현재 활성화된
                                가버너를 볼 수 있습니다.
scaling_governor,               그리고 다른 가버너의 이름을 “echo함”으로써,
                                여러분은 이를 바꿀 수 있습니다. 어떤 가버너는
                                로딩되지 않을 것임을 알아두세요 – 그들은 오직
                                어떤 지정된 아키텍처나 프로세스들 상에서만
                                동작합니다.
cpuinfo_cur_freq :              하드웨어로부터 얻은 그 CPU의 현재 주파수(kHZ).
                                이 것은 CPU가 실제로 실행되는 주파수입니다.
scaling_available_frequencies : 사용가능한 주파수의 목록(KHz)
scaling_min_freq 와
scaling_max_freq                현재의 “정책 제한 사항”을 보여줍니다(kHz).
                                새로운 값들을 이 파일에 echo함으로써,
                                여러분은 이들 제한 사항을 바꿀 수 있습니다.
                                알림: 여러분이 필요로 하는 정책을 셋팅할 때
                                먼저 scaling_max_freq를 셋팅하고, 그 다음
                                scaling_min_freq를 셋팅하세요.
affected_cpus :                 주파수의 소프트웨어 조정이 요구되는 CPU들의 목록
related_cpus :                  소프트웨어든 하드웨어든 일련의 주파수 조정이
                                필요한 CPU들의 목록
scaling_driver :                cpufreq를 위한 하드웨어 드라이버.
scaling_cur_freq :              가버너와 cpufreq 코어에 의해 결정된 그 CPU의
                                현재 주파수(kHz). 이것은 커널이 그 CPU가
                                실행한다고 생각하는 주파수입니다.
bios_limit :                    BIOS가 OS에게 CPU를 더 낮은 주파수로 제한하라고
                                이야기한다면, 사용자는 이 파일로부터 최고
                                사용가능 주파수를 읽을 수 있습니다. 이것은
                                일반적으로 (종종 의도되지 않은) BIOS 셋팅,
                                서비스 프로세서나 다른 BIOS/HW 기준 구현에
                                의해 발생하는 제약으로부터 발생할 수 있습니다. 
                                일반적인 서멀 드라이버로부터 검출될 수 있는
                                서멀 ACPI 제약 사항들을 포함하여 다루지 않습니다.
                                
여러분이 여러분에게 CPU 동작 주파수를 지정된 값으로 셋팅할 수 있는
“userspace” 가버너를 선택했다면, 여러분은 현재 주파수를 다음에서
읽을 수 있습니다.
scaling_setspeed.               새 주파수를 여기로 “echo함”으로써,
                                여러분은 그 CPU의 속도를 바꿀 수 있습니다.
                                그러나 scaling_min_freq와 scaling_max_freq
                                안의 제약사항안에 있어야 합니다.

[Linux:Kernel] Linux CPUFreq CPU Drivers

다솜돌이 Leave a comment

이 문서의 저작권은 GPL 라이센스를 따릅니다.(This document is released under the GPL license.)

             리눅스(TM) 커널 내의 CPU 주파수와 전압 조정 코드


                         L i n u x    C P U F r e q

                           C P U   D r i v e r s 

                           – 개발자를 위한 정보 –


                    Dominik Brodowski  <linux@brodo.de>
                번역: 양정석 <dasomoli@gmailREMOVETHIS.com>



   Clock scaling allows you to change the clock speed of the CPUs on the
    fly. This is a nice method to save battery power, because the lower
            the clock speed, the less power the CPU consumes.


차례:
—–
1.   뭘 해야 하나요?
1.1  초기화
1.2  Per-CPU 초기화
1.3  검증
1.4  target을 쓸까, setpolicy를 쓸까?
1.5  target 호출
1.6  setpolicy 호출
2.   주파수 테이블 헬퍼



1. 뭘 해야 하나요?
==================

그래, 여러분이 막 새 브랜드의 CPU / 칩셋을 데이터 시트와 함께 얻게 됐고,
이 CPU / 칩셋을 위한 cpufreq 지원을 추가하고 싶다고요? 좋습니다. 여기에
필요한 것들에 대한 몇 가지 힌트들이 있어요:


1.1 초기화
———-

무엇보다 먼저, __initcall 레벨 7 (module_init()) 이나 그 이후의 함수 안에서
이 커널이 맞는 CPU와 맞는 칩셋 상에서 실행되는지를 확인하세요. 그렇다면,
struct cpufreq_driver 를 CPUfreq 코어와 함께 cpufreq_register_driver()를
사용해서 등록하세요.

이 struct cpufreq_driver 는 무엇을 포함해야 할까요?

cpufreq_driver.name –           이 드라이버의 이름.

cpufreq_driver.owner –          THIS_MODULE;

cpufreq_driver.init –           per-CPU 초기화 함수로의 포인터.

cpufreq_driver.verify –         “검증” 함수로의 포인터.

cpufreq_driver.setpolicy _또는_ 
cpufreq_driver.target –         아래에서 차이에 대해 살펴보세요.

그리고 옵션으로

cpufreq_driver.exit –           per-CPU 클린업 함수로의 포인터.

cpufreq_driver.resume –         A pointer to a per-CPU resume function
                                which is called with interrupts disabled
                                and _before_ the pre-suspend frequency
                                and/or policy is restored by a call to
                                ->target or ->setpolicy.

cpufreq_driver.resume –         pre-suspend 주파수와(또는) 정책이 ->target
                                이나 ->setpolicy 호출로 복구되기 _전에_
                                인터럽트가 꺼진 상태에서 호출되는 per-CPU
                                resume 함수의 포인터.

cpufreq_driver.attr –           sysfs 로 값을 노출시킬 “struct freq_attr”의
                                NULL로 끝나는 리스트의 포인터.


1.2 Per-CPU 초기화
——————

새 CPU가 디바이스 모델과 등록될 때, 또는 cpufreq 드라이버가 그 스스로를
등록한 후에, per-CPU 초기화 함수 cpufreq_driver.init이 호출됩니다.
그건 struct cpufreq_poliy *policy를 인자로 가져옵니다. 이제 뭘 하죠?

필요하면, 여러분의 CPU 상의 CPUfreq 지원을 활성화하세요.

그러면, 그 드라이버가 다음 값들을 채워넣어야만 합니다:

policy->cpuinfo.min_freq _와_
policy->cpuinfo.max_freq –      이 CPU 가 지원하는 최저/최고 주파수(kHZ)
policy->cpuinfo.transition_latency   이 CPU 상에서 두 주파수 사이에
                                변환되는데 걸리는 나노초 시간(적절하다면
                                맞지만, 아니면 CPUFREQ_ETERNAL 지정).

policy->cur                     (적절하다면) 이 CPU의 현재 동작 주파수
policy->min, 
policy->max, 
policy->policy 그리고, 필요하다면,
policy->governor                이 CPU를 위한 “기본 정책”을 반드시 포함해야
                                함. 조금 지나면, cpufreq_driver.verify와
                                다음 둘 cpufreq_driver.setpolicy 나
                                cpufreq_driver.target 중 하나가 이 값들과
                                함께 호출됩니다.

이들 값들 중 몇을 셋팅하기 위해서 주파수 테이블 헬퍼가 도움이 될 겁니다.
자세한 사항은 섹션 2를 보시면 됩니다.

1.3 검증
——–

사용자가 셋팅하려는 (“policy,governor,min,max”로 구성된) 새로운 정책을
결정하면, 이 정책은 맞지않는 값들이 교정될 수 있도록, 반드시 유효성이
검사되어야 합니다. 이들 값의 검증을 위해서 주파수 테이블 헬퍼와(또는)
cpufreq_verify_within_limits(struct cpufreq_policy *policy, unsigned
int min_freq, unsigned int max_freq) 함수가 도움이 될 겁니다. 주파수
테이블 헬퍼에 대한 자세항 사항은 섹션 2를 보시면 됩니다.

여러분은 적어도 한 유효한 주파수(또는 동작 범위)를 policy->min 과
policy->max 안에서 확인할 필요가 있습니다. 필요하다면 policy->max 를
먼저 증가시키고, 이게 해결 방법이 아닐 때만 policy->min 을 감소시키세요.


1.4 target을 쓸까, setpolicy를 쓸까?
————————————

대부분의 cpufreq 드라이버나 대부분의 CPU 주파수 조정 알고리즘조차도
한 주파수로만 CPU를 셋팅할 수 있습니다. 이를 위해서 여러분은
->target 함수를 사용합니다.

어떤 cpufreq 가능한 프로세서들은 주파수를 확실한 그들만의 제약사항 사이에서
변환합니다. 이들은 ->setpolicy 함수를 사용하는 것이 좋습니다.

1.4. target 호출
—————-

target 호출은 세가지 인자를 가집니다: struct cpufreq_policy *policy,
unsigned int target_frequency, unsigned int relation.

CPUfreq 드라이버는 여기에서 불려지는 때에 새 주파수를 반드시 셋팅해야
합니다. 실제 주파수는 다음 규칙을 사용해서 결정되어야만 합니다:

– “target_freq” 에 가깝게 유지
– policy->min <= new_freq <= policy->max (이건 반드시 유효해야 합니다!!!)
– relation==CPUFREQ_REL_L 라면, new_freq를 target_freq와 같거나 더 높게 선택
  하도록 시도합니다. (“더 낮은 이 아닌, 최저(lowest)를 위한 L”)
– relation==CPUFREQ_REL_H 라면, new_freq를 target_freq와 같거나 더 낮게 선택
  하도록 시도합니다. (“더 높은 이 아닌, 최고(highest)를 위한 H”)

여기서 다시, 주파수 테이블 헬퍼는 여러분을 도와줄 수 있습니다 – 자세한
사항은 섹션 2를 보세요.


1.5 setpolicy 호출
——————

setpolicy 호출은 오직 struct cpufreq_policy *policy 만 인자로 가집니다.
여러분은 가장 낮은 프로세서 내부나 칩셋 내부 동적 주파수 변환의 더 낮은
제약사항을 policy->min으로, 더 높은 제약사항을 policy->max로, 그리고
-만약 지원한다면- policy->policy 가 CPUFREQ_POLICY_PERFORMANCE 일 때,
성능 지향형 셋팅을, 그리고 CPUFREQ_POLICY_POWERSAVE 일 때, 전력 절약
형 셋팅을 설정할 필요가 있습니다. 또한 drivers/cpufreq/longrun.c 안의
참고 구현을 확인하세요.



2. 주파수 테이블 헬퍼
=====================

대부분의 cpufreq 프로세서들이 몇 가지 지정된 주파수만 셋팅할 수 있는
것처럼, 이런 동작의 “주파수 테이블”은 그 프로세서 드라이버의 어떤 동작에
도움이 될 것입니다. 앞에서 언급된 “주파수 테이블”은 여러분이 사용하길
원하는 “index”내에 어떤 값을, 그리고 “frequency” 안에 해당하는 주파수로 된
struct cpufreq_freq_table 항목의 배열로 구성되어 있습니다. 테이블의 끝에,
여러분은 cpufreq_freq_table 항목의 frequency에 CPUFREQ_TABLE_END로 셋팅할
필요가 있습니다. 그리고 테이블 안의 한 항목을 그냥 넘기길 원한다면,
frequency를 CPUFREQ_ENTRY_INVALID로 셋팅하면 됩니다. 그 항목이 증가하는
순서로 있을 필요는 없습니다.

cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
                                struct cpufreq_frequency_table *table); 의
호출을 통해 cpuinfo.min_freq와 cpuinfo.max_freq 값들이 검출됩니다. 그리고
policy->min 과 policy->max로 같은 값이 셋팅됩니다. 이것은 per-CPU 초기화
단계에서 유용합니다.

int cpufreq_frequency_table_verify(struct cpufreq_policy *policy,
                                   struct cpufreq_frequency_table *table);
는 적어도 한 개의 유효한 주파수가 policy->min과 policy->max 안에 있고,
모든 다른 조건들을 만족한다는 것입니다. 이것은 ->verify 호출에서
유용합니다.

int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
                                   struct cpufreq_frequency_table *table,
                                   unsigned int target_freq,
                                   unsigned int relation,
                                   unsigned int *index);

는 ->target 단계를 위한 맞는 주파수 테이블 헬퍼입니다. 그냥 값들을
이 함수로 넘기면 되고, 그 CPU가 셋팅될 주파수를 포함하는 주파수
테이블 항목의 번호를 unsigned int index로 반환합니다. 알림: 이것은
이 cpufreq_table_entry.index 안의 “index”가 아니고,
cpufreq_table[index] 대신입니다. 그래서 새로운 주파수는
cpufreq_table[index].frequency 이고, 여러분이 주파수 테이블 “index”
필드로 저장한 그 값은 cpufreq_table[index].index 입니다. [*]

* 역자 주: 주파수 테이블의 index 라는 이름이 혼동스러워서 driver_data 로
이름이 변경되었습니다. 그래서 이 줄은 문서에서 삭제되었습니다.

[Linux:Kernel] Linux CPUFreq Governor

다솜돌이 2 Comments

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

              리눅스(TM) 커널 안의 CPU 주파수와 전압 조정 코드
                         L i n u x    C P U F r e q

                      C P U F r e q   G o v e r n o r s

                      – 사용자와 개발자들을 위한 정보 –

                    Dominik Brodowski  <linux@brodo.de>
                  추가와 교정은 Nico Golde <nico@ngolde.de>
                 번역 : 양정석 <dasomoli@gmailREMOVETHIS.com>
   Clock scaling allows you to change the clock speed of the CPUs on the
    fly. This is a nice method to save battery power, because the lower
            the clock speed, the less power the CPU consumes.
차례:
—–
1.   CPUFreq 가버너가 뭔가요?

2.   리눅스 커널 안의 가버너들
2.1  성능(Performance)
2.2  전력절약(Powersave)
2.3  사용자공간(Userspace)
2.4  수요충족(Ondemand)
2.5  보수적(Conservative)
2.6  상호적(Interactive)

3.   CPUfreq 코어 안의 가버너 인터페이스

1. CPUFreq 가버너가 뭔가요?
===========================

대부분의 cpufreq 드라이버들(사실, longrun 하나를 빼고 모두다) 또는 대
부분의 cpu 주파수 조정 알고리즘조차 오직 CPU에 하나의 주파수를 셋팅
하는 것만을 제공합니다. 동적인 주파수 조정을 제공함에 따라 cpufreq
코어는 한 “목표 주파수”의 이들 드라이버들을 말할 수 있어야만 합니다.
그래서 이들 지정된 드라이버들은 원래 있던 “->setpolicy” 호출 대신에
“->target” 호출을 제공하도록 바뀔 것입니다. “longrun”을 위해 모두가
같게 머물긴 하겠지만 말입니다.

CPUFreq 정책 안에서 무슨 주파수가 사용되어져야 하는 지는 어떻게 결정할
까요? 그건 “cpufreq 가버너”를 사용해서 합니다. 이 패치에는 이미
두 개가 있습니다– 주파수를 정적으로 가장 낮게 또는 가장 높은 주파수로
설정하는 “powersave”와 “performance” 가 이미 각각 있습니다.
적어도 둘 이상의 이같은 가버너가 수시일 내에 추가될 준비가 될 겁니다.
그러나 동적 주파수 조정에 관한 수많은 다른 이론과 모델들이 있는 것처럼
더 많이 될 것 같아 보입니다. cpufreq로서 그런 일반적인 인터페이스의
사용은 조정 가버너들에게 이들은 널리 테스트될 수 있다는 것과, 각각의 특정
용도에 대해 선택될 수 있는 가장 좋은 것을 제공합니다.

기본적으로, 다음 흐름도를 따릅니다:

CPU는 기정된 “제한사항”안에서 독립적으  |        CPU는 지정 주파수로만
로 스위칭될 수 있음                     |           셋팅될 수 있음

                                  “CPUfreq 정책”
                은 주파수 제한(policy->{min,max})과 사용될 CPUFreq로
                                   구성됩니다
                         /                    \
                        /                      \
                       /                       cpufreq 가버너가 (동적으로 혹은
                      /                         정적으로) policy->{min,max}의
                     /                         제한 사항안에서 무슨 target_freq를
                    /                          사용할 지 결정합니다.
                   /                                \
                  /                                  \
        ->setpolicy 호출을 사용하여,            ->target 호출을 사용하여,
         제한 사항과 “정책”을 셋팅.              가장 가까운 주파수를 target_freq
                                                 로 셋팅. policy->{min,max} 안에
                                                 있음이 보장됨.

2. 리눅스 커널 안의 가버너들
============================

2.1 성능(Performance)
———————

CPUfreq 가버너 “performance”는 CPU를 정적으로 scaling_min_freq 와
scaling_max_freq 경계 안에서 가장 높은 주파수로 셋팅합니다.
2.2 전력절약(Powersave)
———————–

CPUfreq 가버너 “powersave”는 CPU를 정적으로 scaling_min_freq 와
scaling_max_freq 경게 안에서 가장 낮은 주파수로 셋팅합니다.
2.3 사용자공간(Userspace)
————————-

CPUfreq 가버너 “userspace”는 사용자에게, 또는 UID “root”로 실행되는
어떤 사용자공간 프로그램에게 CPU-device 디렉토리 안에 이용가능한
“scaling_setspeed” sysfs 파일을 만듦으로써 CPU를 지정된 주파수로
셋팅할 수 있도록 합니다.
2.4 수요충족(Ondemand)
———————-

CPUfreq 가버너 “ondemand” 는 현재 사용량에 따라 CPU를 셋팅합니다.
이를 수행하기 위해 CPU는 매우 빠르게 주파수를 바꿀 수 있는 능력을
가져야 합니다. 접근 가능한 파라메터 sysfs 파일이 몇 개 있습니다:

sampling_rate: uS(10^-6 초)로 측정됨, 이것은 얼마나 자주 여러분이 커널이
CPU 사용량을 살펴보고 주파수에 관해 무엇을 할 것인지에 대한 결정을 내리길
원하는지 입니다. 일반적으로 이것은 ‘10000’ 주변이나 그 이상 값으로 셋팅
됩니다. 기본값은 (users-guide.txt와 절충하여):
transition_latency * 1000
전이 지연 시간은 ns 이고 sampling_rate는 us 임을 명심하세요. 그래서 여러분은
기본적으로 같은 sysfs 값을 얻을 수 있습니다.
샘플링 레이트는 언제나 전이 지연 시간을 고려해서 조정되어야만 합니다.
bash 에서 샘플링 레이트를 전이 지연 시간의 750 배 높은 값(말했듯이, 기본값은
1000)으로 셋팅하려면:
echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) \
    >ondemand/sampling_rate

sampling_rate_min:
샘플링 레이트는 HW 전이 지연 시간에 의해 제한됩니다:
transition_latency * 100
또는 커널 제한에 의해서요:
CONFIG_NO_HZ 가 셋팅되면, 제한은 10ms 고정값.
CONFIG_NO_HZ 가 셋팅되지 않거나 부트 파라미터로 nohz=off 가 사용되면,
그 제한은 CONFIG_HZ 옵션에 의해 결정됩니다:
HZ=1000: min=20000us  (20ms)
HZ=250:  min=80000us  (80ms)
HZ=100:  min=200000us (200ms)
커널의 가장 높은 값과 HW 전이 지연 제한이 나타나고, 가장 작은 샘플링 레이트
가 사용됩니다.

up_threshold: 주파수를 증가시키는 게 좋을지에 대한 결정을 커널이 내리는데
필요한 ‘sampling_rate’의 샘플링들 사이의 평균 CPU 사용량으로 정의됩니다.
예를 들면, 그 값이 ’95’로 셋팅되어 있을 때는 검사 간격 사이에 CPU가 평균
95% 이상 사용 중이면 CPU 주파수를 증가시킬 필요가 있다는 결정을 함을
의미합니다.

ignore_nice_load: 이 파라미터는 ‘0’ 또는 ‘1’ 을 값으로 가집니다.
‘0’ 으로 셋팅되었을 때(기본값)는 모든 프로세스들이 ‘CPU 활용도’ 값을 위해
세어집니다. ‘1’ 로 셋팅되었을 때는 ‘nice’ 값으로 실행되는 프로세스들은
전체 사용량 계산에 같이 세어지지 않습니다. 이 것은 여러분이 여러분의
랩탑에서 ‘nice’ 를 사용하여 끝나는 시간이 얼마나 오래 걸릴지를 걱정하지
않는 CPU를 많이 사용하는 심한 계산을 실행 중일 때 유용하고, 여러분의
CPU 주파수를 증가시키는데 그 프로세스가 영향을 미치는 것을 막아줍니다.

sampling_down_factor: 이 파라미터는 커널이 최고 속도에서 실행 중인 동안
주파수를 언제 감소시킬 것인지를 결정하는 속도을 제어합니다. 1(기본값)로
셋팅되었을 때는 다시 부하를 평가하기 위한 결정이 현재 클럭 속도와 상관없이
같은 간격에서 이루어 집니다. 그러나 1 보다 크게(예를 들어, 100) 셋팅되면
CPU가 높은 부하로 인해 그 최소 속도로 있을 때, 부하의 재평가를 위한
스케줄링 간격의 배수로서 수행됩니다. 이것은 부하 평가의 과부하를 줄임으로써
성능을 향상시키고, CPU 가 정말 바쁠 때 다시 느려졌다가 빨라지는 것보다 나은,
그 최고 속도를 유지하도록 도움을 줍니다. 이것은 낮은 속도/낮은 CPU 부하량의
동작에는 영향을 주지 않습니다.
2.5 보수적(Conservative)
————————

“ondemand”와 매우 비슷한, CPUfreq 가버너 “conservation” 는 현재 사용량에
따라 CPU 를 셋팅합니다. 그것은 동작 상에서, 어떤 CPU 상의 부하가 있는
순간 최고 속도로 점프하는 것보다는 우아하게 CPU 속도를 증가시키고
감소시킨다는 것이 다릅니다. 이 동작은 배터리 전원 환경에 더 잘어울립니다.
이 가버너는 다음의 몇 개 추가된 sysfs를 통해 “ondemand” 가버너와 같은
방식으로 조작할 수 있습니다:

freq_step: 이것은 CPU 주파수가 그에 의해 부드럽게 중가되거나 감소되어야
하는지 백분율로 표시된 단계를 나타냅니다. 기본적으로 CPU 주파수는 여러분의
CPU 최고 주파수의 5% 단위로 증가할 것입니다. 여러분은 이 값은 어느 곳에서나
0과 100사이에서 바꿀 수 있습니다. ‘0’은 그 부하에 상관없이 어느 속도로
여러분의 CPU 속도를 효과적으로 고정시킬 것입니다. 반면 ‘100’은 이론적으로
“ondemand” 가버너와 동일하게 동작하도록 합니다.

down_threshold: “ondemand” 가버너에서 찾을 수 있는 ‘up_threshold’ 와 같지만,
방향은 반대입니다. 예를 들면, 그 기본값이 ’20’으로 셋팅되었을 때는 그
주파수를 낮추려면 CPU 사용량이 샘플링 간격 사이에 20% 아래일 필요가 있다는
의미입니다.

2.6 상호적(Interactive)
———————–

CPUfreq 가버너 “interactive”는 지연 시간에 민감한 상호적 작업 부하에
맞추어 설계되었습니다. 이 가버너는 CPU 속도를 “ondemand” 와
“conservative” 가버너와 비슷하게, 사용량에 따라 셋팅합니다. 그러나
설정가능한 동작들이 다릅니다.

이 가버너를 위해 맞출 수 있는 값들은 다음과 같습니다:

target_loads: CPU 부하 값은 현재 CPU 부하를 그 값으로 맞추기 위해서
속도를 조정하는데 사용됩니다. 일반적으로, 목표 부하값이 낮을수록
더 자주 그 가버너가 목표 아래로 부하를 낮추기 위해 CPU 속도를
끌어올릴 것입니다. 그 형식은 하나의 목표 부하값, 그 다음 옵션으로
목표하거나 그 이상의 속도를 위한 CPU 부햐와 CPU 속도의 짝입니다.
콜론이 속도, 그리고 그와 관련된 목표 부하량을 읽기 쉽게 하기 위해
사용될 수 있습니다. 예를 들면:

   85 1000000:90 1700000:99
   
CPU 부하가 1GHz 이하에서는 85%를 목표로 하고, 90%는 1GHz에서나 그 이상
1.7GHz까지, 그리고 그 이상은 99%를 목표로 합니다. 속도가 지정되면
이들은 증가하는 순서로 나와야 합니다. 높은 목표 부하값들은 일반적으로
높은 속도로 지정되고, 그래서 목표 부하값 또한 보통 증가하는 순서로
나타납니다. 기본값은 모든 속도에 목표 부하 90% 입니다.
min_sample_time: 낮추기 전에 현재 주파수에서 소비할 시간의 최소량.
기본값은 80000 uS.

hispeed_freq: gp_hispeed_load 로 지정된 값에 CPU 부하가 도달했을 때
처음에 증가하는 중간급의 “처음 만나는 속도”. 부하가 above_hispeed_delay에
지정된 시간의 양 동안 높게 유지되면, 속도는 더 빨라집니다. 기본값은
가버너의 초기화 시간에 그 정책에 의해 허용되는 최고 속도입니다.

go_hispeed_load: hispeed_freq 로 올라가는 CPU 부하. 기본은 99%.

above_hispeed_delay: 속도가 hispeed_freq 혹은 그 이상일 때, 계속되는
고부하로 인해 속도를 올리기 전에 이 시간만큼 대기합니다.
이 형식은 하나의 대기 시간 값, 그 다음 옵션으로 CPU 속도와 이들 속도
혹은 그 이상의 속도에서 사용되는 대기 시간의 짝이 따릅니다. 콜론이
읽기 쉽게 하기 위해 속도와 그 연관된 대기 시간 사이에 사용될 수
있습니다. 예를 들면:

   80000 1300000:200000 1500000:40000

CPU 속도 1.3 GHz 까지는 80000 uS 대기 시간이 사용되고, 1.5 GHz
속도까지는 200000 uS가 속도 대기 시간으로, 1.5 GHz(그리고 그 이상)
에서는 40000 uS 대기 시간이 사용됩니다. 속도들이 지정되면 이들은
증가하는 순서로 나타나야 합니다. 기본값은 20000 uS.

timer_rate: CPU가 대기 상태가 아닐 때 CPU 부하를 재평가하기 위한
샘플링 속도. 한 개의 미룰 수 있는 타이머가 사용되는데, 어떤 다른 것을
실행될 필요가 있을 때까지 CPU는 대기 상태로부터 이 타이머를 수행할
때까지 깨어나지 않게 됩니다. (최하 속도에서 실행되지 않을 때 이
타이머를 미룰 수 있는 최대 시간은 timer_slack을 통해 설정 가능합니다)
기본값은 20000 Us.

timer_slack: 최하 속도 이상의 속도로 실행 중일 때, timer_rate를 넘어
가버너의 샘플링 타이머의 처리를 미룰 수 있는 최대 추가 시간. CPU들이
최하보다 높은 속도로 실행 중일때 대기 상태에서 추가 전력을 소비하는
플랫폼을 위해 이것은 타이머가 얼마나 오래 부하 재평가와 속도를
떨어뜨리는 것의 순위를 미룰 것인가 상한을 둡니다. 예를 들면, timer_rate
가 20000uS 이고 timer_slack 이 10000uS 이면, 타이머는 최하 속도에 있지
않을 때, 최대 30msec 까지 수행을 미룰 것입니다. -1 값은 타이머를 모든
속도에서 무한히 미루겠다는 뜻입니다. 기본은 80000 uS.

boost: 0이 아니면, 즉시 모든 CPU들의 속도를 이 속성에 0이 쓰여질 때까지
적어도 hispeed_freq 까지 일시적으로 올립니다. 0이면, 보통의 부하에
따라 CPU 속도를 hispeed_freq 아래로 떨어지는 것이 허용됩니다.
기본값은 0.

boostpulse: 쓰여질 때마다, 즉시 모든 CPU들의 속도를 적어도
boostpulse_duration에 지정된 시간 동안 hispeed_freq로 일시적으로
올리고, 그 후에 보통의 부하에 따라 hispeed_freq 아래로 속도가 떨어지는
것이 허용됩니다.

boostpulse_duration: boostpulse에 쓰여질 때 보통의 부하에 따라 속도를
떨어뜨리는 것을 허용하기 전에 hispeed_freq 에서 CPU 속도를 유지하는
시간의 길이. 기본값은 80000 uS.
3. CPUfreq 코어 안의 가버너 인터페이스
======================================

새로운 가버너는 그 자신을 CPUfreq 코어에 “cpufreq_register_governor”를
사용해서 반드시 등록해야 합니다. 그 함수로 전달될
struct cpufreq_governor 는 다음 값들을 반드시 가져야 합니다:

governor->name –            이 가버너의 유일한 이름
governor->governor –        가버너 콜백 함수
governor->owner –           (적절하다면) 가버너 모듈을 위한 .THIS_MODULE

governor->governor 콜백은 그 CPU를 위한 현재의(또는 셋팅될)
cpufreq_policy 구조체, unsigned int인 event와 함께 호출됩니다. 다음의
event들이 현재 정의되어 있습니다:

CPUFREQ_GOV_START:   이 가버너가 그 CPU policy->cpu를 위해 그 의무를
                     시작할 것입니다.
CPUFREQ_GOV_STOP:    이 가버너가 그 CPU policy->cpu를 위해 그 의무를
                     멈출 것입니다.
CPUFREQ_GOV_LIMITS:  CPU policy->cpu를 위한 제한 사항들이 policy->min
                     과 policy->max로 바뀌었습니다.

여러분이 여러분의 드라이버의 다른 “이벤트들”을 외부적으로 필요로 한다면,
CPUFreq 코어가 적절한 락킹을 보장하도록 _오직_
cpufreq_governor_l(unsigned int cpu, unsigned int event) 호출만 사용하도록
하세요.
CPUfreq 가버너는 아마 이들 두 함수 중 하나를 사용해서 CPU 프로세서
드라이버를 호출할 것입니다:

int cpufreq_driver_target(struct cpufreq_policy *policy,
                                 unsigned int target_freq,
                                 unsigned int relation);

int __cpufreq_driver_target(struct cpufreq_policy *policy,
                                   unsigned int target_freq,
                                   unsigned int relation);

target_freq 는 물론, policy->min과 policy->max 안에 있어야만 합니다.
이들 두 함수간에 무슨 차이가 있을까요? 여러분의 가버너가 여전히
governor->governor 로 호출의 직접적인 코드 경로 안에 있다면, per-CPU
cpufreq lock 이 cpufreq 코에 안에서 여전히 잡혀 있을 것이고, 다시
잠글 필요가 없습니다(사실 이렇게 하면 데드락의 원인이 됩니다). 그래서
이런 경우에는 __cpufreq_driver_target 만 사용하세요. 다른 모든 경우에는
(예를 들면, 매 초마다 깨어나는 “데몬화된” 함수가 있을 때), 그 명령이
cpufreq 프로세서 드라이버로 전달되기 전에 cpufreq per-CPU lock을
락킹하기 위해서 cpufreq_driver_target을 사용하세요. 

[Linux:Kernel] Linux CPUFreq Core

다솜돌이 Leave a comment

이 문서의 저작권은 GPL License를 따릅니다(This document is released under the GPL license).

  리눅스(TM) 커널안의 CPU 동작속도와 전압 조절 코드 
        L i n u x    C P U F r e q
 C P U F r e q    C o r e
   Dominik Brodowski  <linux@brodo.de>
    David Kimdon <dwhedon@debian.org>
번역 : 양정석 <dasomoli@gmailREMOVETHIS.com>

   클럭 조정은 동작하고 있는 CPU의 클럭 속도를 바꿀 수 있게 합니다. 이 것은

    배터리 파워를 절약할 수 있는 좋은 방법입니다. 왜냐하면 클럭 속도가
   낮을수록 CPU가 소비하는 전력도 낮아지기 때문입니다.

    

차례:

—–

1.  CPUFreq 코어와 인터페이스

2.  CPUFreq 노티파이어(notifires)

1. 일반적인 정보

================

CPUFreq 코어 코드는 drivers/cpufreq/cpufreq.c 안에 있습니다. 이 cpufreq

코드는 CPUFreq 구조 드라이버(실제 주파수 전이를 수행하는 코드 조각)를

위한 표준화된 인터페이스, “노티파이어(notifires)”를 제공합니다. 이들은 정책 변경

(예를 들면, ACPI 같은 온도 모듈), 모든 동작 속도 변화(예를 들면,

타이밍 코드)의 알림을 필요로 하거나, 혹은 일정 속도 제한을 강제할 필요가

있는(예를 들면, ARM 아키텍처의 LCD 드라이버 같은) 디바이스 드라이버거나

혹은 커널의 다른 부분 입니다. 추가적으로, 커널 “상수” loops_per_jiffy는

여기 주파수 변경 상에서 업데이트 됩니다.

레퍼런스 카운트는 cpufreq 프로세서 드라이버가 코어와 함께 정확히

등록되었고, cpufreq_put_cpu가 호출되기 전까지 로딩되지 않을 것임을

확실하게 해주는 cpufreq_get_cpu와 cpufreq_put_cpu에 의해서 수행됩니다.

2. CPUFreq 노티파이어(notifires)

================================

CPUFreq 노티파이어는 표준 커널 노티파이어 인터페이스를 따릅니다.

노티파이어에 대한 자세한 사항은 linux/include/linux/notifire.h 를

보세요.

두가지 CPUFreq 노티파이어-정책 노티파이어와 전이 노티파이어-가 있습니다.

2.1 CPUFreq 정책 노티파이어

—————————

새 정책이 셋팅되려고 할 때 이것들이 알려집니다. 각 CPUFreq 정책 노티파이어는

정책의 전이 동안 세 번 호출 됩니다:

1.) CPUFREQ_ADJUST 동안 모든 CPUFreq 노티파이어는 이를 봐야 할 필요가 있다면

   그 제한 사항-온도에 대한 고려나 하드웨어 제한 사항-을 변경할 것입니다. 

2.) CPUFREQ_INCOMPATIBLE 동안 하드웨어 실패를 피하기 위한 변경들만 수행될

   것입니다.

3.) 그리고 CPUFREQ_NOFITY 동안 모든 노티파이어들은 새 정책-만약 두 하드웨어

   드라이버가 이 단계 전에 새 정책에 대해 동의하는데 실패했다면, 그 호환될 수

   없는 하드웨어는 꺼지고 사용자에게 이를 알릴 것입니다-을 알립니다.

이들 단계는 노티파이어의 두번째 인자로 지정됩니다.

세번째 인자, void * 포인터는 다섯 개의 값으로 구성된  cpufreq_policy 구조체를

가리킵니다: cpu, min, max, policy와 max_cpu_freq. min과 max는 새 정책의 

주파수의 상한과 하한 값(kHz) 을, policy는 새 정책, cpu는 영향을 미칠 CPU의

번호, 그리고 max_cpu_freq 는 최고로 지원하는 CPU 주파수입니다. 이 값은

정보 제공 목적으로만 주어집니다.

2.2 CPUFreq 전이 노티파이어

—————————

이 것들은 CPUFreq 드라이버가 CPU 코어 주파수를 바꿀 때와 이 변경이 어떤 외부

영향을 가질 때, 두 번 알려집니다.

두번째 인자는 이들 단계-CPUFREQ_PRECHANGE나 CPUFREQ_POSTCHANGE-를 지정합니다.

세번째 인자는 다음 값들을 가지는 cpufreq_freq 구조체입니다:

cpu – 영향을 미치는 CPU 번호

old – 이전 주파수

new – 새 주파수

시스템이 suspend된 동안 cpufreq 코어가 주파수의 변경을 알아차리면,

이들 노티파이어는 두번째 인자로 CPUFREQ_RESUMECHANGE와 함께 호출됩니다.