Linux의 스케줄링 태스크는 복잡하다. Linux는 엔터프라이즈 서버, 클라이언트 데스크탑 및 임베디드 디바이스와 같은 다양한 사용 모델에서 싱글 코어, 멀티 코어, 멀티 코어/멀티 스레드 등과 같은 광범위한 프로세서 토폴로지로 작동한다. 놀랍게도 Linux에 있는 소수의 스케줄링 정책은 전혀 작동하지 않는다.

게다가 스케줄러가 커널 내부 깊은 곳에 있어서 Linux에서 스케줄링 정책의 효율을 측정하기도 어렵다. 추적과 같은 인트로스펙션을 추가하면 실제로 스케줄러의 작동이 변경되며 결함이나 비효율성이 드러나지 않는다. 더욱이 다양한 프로세서 토폴로지에서 특정 워크로드의 유효성을 검증하기 위해 스케줄링 시나리오를 설정하면 좌절하게 된다.

다행히도 LinSched와 같은 프로젝트(사용자 공간 Linux 스케줄러 시뮬레이터)를 이용하면 이러한 문제점을 쉽게 해결할 수 있다.

LinSched 소개

LinSched는 사용자 공간에서 상주하는 Linux 스케줄러 시뮬레이터이다. LinSched는 Linux 스케줄러 서브시스템을 분리하고 그 주위에 사용자 공간에서 이 서브시스템을 실행할 수 있는 충분한 커널 환경을 구축한다. 또한, 필수 도구를 제공하여 워크로드 스케줄링의 유효성을 검증하고 작동을 이해하기에 충분한 관련 데이터를 수집하기 위해 그 주위에 API 세트를 구축한다.

스케줄러를 사용자 공간으로 가져오면 스케줄러가 파손되어도 전체 시스템이 중단되지 않기 때문에 스케줄러를 실행하기가 쉽다. 또한, 쉽고 효과적으로 데이터를 수집하여 로컬 파일 시스템에 저장할 수 있기 때문에 스케줄러와 관련된 데이터를 수집하기 쉽다.

가상화를 사용할 수도 있지만 다른 커널을 부팅할 필요가 없기 때문에 LinSched는 단순하고 효율적이라는 장점을 제공한다. 또한, 사용자 공간 프로세스인 LinSched는 GDB(GNU Debugger)와 같은 디버거를 연결하여 스케줄러의 조작을 훨씬 더 쉽고 면밀하게 검토할 수 있다.

위로

LinSched의 기원

LinSched는 원래 IBM과 Intel에서 승인을 받아서 노스캐롤라이나대학교에서 개발했지만 최근에 스케줄링 정책의 유효성을 검증하기 위해 Google에서 복원했다. 이러한 사실은 흥미로운 움직임이며 앞으로의 경향을 대변한다고 할 수 있다. Linux에서 많은 스케줄링 클래스를 지원하고 많은 워크로드를 처리하는 데 합당한 스케줄링 작업을 수행한다고 하더라도 Linux는 주어진 하드웨어 토폴로지에서 특정 워크로드를 처리하기에는 적합하지 않다. Google에서 특정 태스크(예: MapReduce)를 수행하는 이상적인 시스템으로 구성된 대용량 클러스터에 투자하고 있기 때문에 스케줄이 이러한 태스크와 환경에 맞게 조정될 것으로 보인다. LinSched를 사용하는 과정에서 Google은 태스크 간에 가중치가 크게 차이 날 때 대역폭을 프로비저닝하고 로드를 조정하는 기능을 포함하여 CFS(Completely Fair Scheduler)의 기능을 강화함으로써 Linux에 기여하기도 했다.

위로

LinSched 아키텍처

LinSched는 사용자 공간에서 실행하는 스케줄러 시뮬레이터의 기능을 넘어서 필수 컴포넌트의 씬 에뮬레이션을 사용하여 Linux 스케줄러를 사용자 공간으로 마이그레이션함으로써 스케줄러가 커널 외부에서 실행할 수 있게 한다. 사실상 LinSched 소스는 랩퍼와 시뮬레이션 엔진을 위한 ./linsched라고 하는 새로운 서브디렉토리가 포함된 Linux 배포판(현재 2.6.35)이다. LinSched는 Linux 내에서 Linux 스케줄러 서브시스템을 사용하여 시뮬레이션하기 때문에 그것을 변경하여 다시 커널에 통합하기가 훨씬 더 쉽다.

LinSched의 전체 아키텍처는 그림 1에 표시되어 있다. 맨 밑에 있는 것은 호스트 운영 체제이다. LinSched는 Linux 커널 일부를 포함하여 다수의 컴포넌트로 빌드된 사용자 공간 애플리케이션이다.

환경 모듈에서는 시뮬레이션 모드에서 컴파일을 지원하기 위한 플래그와 함께 추상화된 Linux 커널을 제공한다. 환경 모듈 위에는 시뮬레이션 엔진이 있는데 이 엔진은 환경을 구성하여 시뮬레이션을 수행하는 과정에서 사용할 수 있게 API를 확장한다. 시뮬레이션 엔진 API는 프로세스 토폴로지를 정의할 초기화 함수뿐만 아니라 태스크 작성 함수, 콜백(예를 들면, 태스크를 스케줄링할 때) 및 run 함수(내부 Linux schedule() 함수를 차례로 호출하여 스케줄링을 결정하는 시뮬레이션을 일정 시간 동안 수행할)를 제공한다.

시뮬레이션 엔진 위에는 실제 시뮬레이션에 필요한 코드인 스크립트 환경이 있다. 스크립트 환경은 하나의 스크립트가 될 수 있지만, 앞으로 나올 예제에서 보듯이 기존 스크립트 환경을 수정하여 테스트 시나리오를 추가하는 것이 가장 간단하게 사용하는 방법이다.

LinSched의 기본 아키텍처는 매우 간단하다. 먼저 LinSched를 설치하는 방법을 살펴본 다음, 확장된 API 일부와 시뮬레이션 과정에서 이 API를 사용하는 방법을 논의하도록 하자.

위로

LinSched 설치

LinSched는 2.6.35 커널을 지원하도록 최근에 업데이트되었다. 현재 LinSched 패키지는 git를 사용하거나 프로젝트 웹 페이지(참고자료 참조)를 통해 얻을 수 있다. git를 사용하여 배포판을 얻으려면 다음과 같이 저장소를 복제한다.

$ git clone git://google3-2.osuosl.org/linsched/2.6.35.git

어떠한 경우든지 배포판이 포함되어 있는 2.6.35/ 서브디렉토리를 얻을 수 있다. LinSched 서브디렉토리에서 다음 명령행을 실행하여 신속하게 테스트를 수행할 수 있다.

$ make run_all_tests

이 명령행은 다양한 프로세스 토폴로지를 대상으로 많은 스케줄러를 수행하여 그 테스트 결과를 표시한다.

위로

LinSched API

LinSched 시뮬레이션을 수행하려면 스크립트를 작성하고 초기화 세트를 수행하여 원하는 시나리오를 설정해야 한다. 이러한 초기화는 LinSched API를 대상으로 하는 일련의 호출을 통해 수행된다. 이 섹션에서는 중요한 API 함수를 일부 살펴보며 사용 방법은 나중에 설명한다. 아래에서 전체 API를 모두 설명하는 것은 아니다. 그러나 ./linsched에 있는 소스 파일에서 더욱 상세한 목록을 확인할 수 있다.

시뮬레이션을 실행하기 전에 시뮬레이터를 초기화해야 한다. linsched_init를 호출하여 초기화를 수행할 수 있다. 이 함수는 시뮬레이션된 프로세서 토폴로지를 인수로 받고 내부에서 시뮬레이터 환경을 구성하여 사용자 공간 Linux 커널을 시작한다.

void linsched_init( struct linsched_topology *topo );

linux_linsched.h에 정의된 토폴로지 구조에서 프로세서 수와 프로세서가 서로 연관되는 방법(실제 패키지와 노드 간격 맵)을 정의한다. TOPO_UNIPROCESSOR로 싱글 프로세서 패키지를 지정하거나 TOPO_QUAD_CPU_QUAD_SOCKET으로 네 개의 소켓으로 구성된 쿼드 코어 프로세서 토폴로지를 지정할 수 있다.

LinSched를 통해 다수의 태스킹 시나리오를 작성하는 작업을 제어할 수 있다고 하더라도 LinSched 내에 있는 태스크는 시뮬레이션된 엔티티이다. 가장 유용한 함수 중 하나는 busy/sleep 구성을 수행할 태스크 수를 작성하는 함수이다. 이 호출자는 작성할 태스크 수(count)와 이러한 태스크에서 실행할 수 있는 프로세서 마스크(mask) 및 sleep/busy 틱 수(sleep과 run으로 식별됨)를 제공한다.

void create_tasks( unsigned int count, unsigned long mask, int sleep, int run );

특정 태스킹 시나리오를 더 많이 작성하기 위해 태스크 작성 API 함수를 추가로 많이 사용할 수 있다(목록 1 참조). 이러한 함수에서는 특정 우선순위나 nice 레벨을 사용하여 정상, 일괄처리 또는 실시간 태스크(선입선출(FIFO) 또는 라운드 로빈)를 작성할 수 있다. 정상 태스크를 작성하면 스케줄링 정책이 SCHED_NORMAL로 설정되고 여기에서 batch, RTfifo 및 RTrr은 각각 SCHED_BATCH, SCHED_FIFO 및 SCHED_RR로 설정된다. 사용자는 특정 태스크가 작동하는 방법을 제어할 태스크 구조를 제공하거나 linsched_create_sleep_run API 함수를 사용하여 일반 sleep/busy 태스크를 작성할 수 있다. 이러한 각 태스크는 linux_linsched.c에서 찾을 수 있다.

	
int linsched_create_normal_task( struct task_data* td, int niceval );
void linsched_create_batch_task( struct task_data* td, int niceval );
void linsched_create_RTfifo_task( struct task_data* td, int prio );
void linsched_create_RTrr_task( struct task_data* td, int prio );
struct task_data *linsched_create_sleep_run( int sleep, int busy );

API를 통해, 태스크 그룹을 작성하여 이러한 그룹에 태스크를 첨부할 수 있을 뿐만 아니라 이 그룹에서 공유할 프로세서를 태스크 스케줄링을 위해 추가할 수도 있다. 목록 2에는 linux_linsched.c에서 찾을 수 있는 이러한 함수로 구성된 목록이 있다.

	
int linsched_create_task_group( int parent_group_id );
void linsched_set_task_group_shares( int group_id, unsigned long shares );
int linsched_add_task_to_group( int task_id, int group_id );

시뮬레이션을 시작하려면 linsched_run_sim을 호출한다. 이 호출은 실행할 틱 수만을 인수로 받는다. 스케줄링을 결정하는 데 필요한 포텐셜이 각 틱에서 작성된다. 시뮬레이션이 완료되면 이 함수가 그 결과를 리턴하며 이 함수는 hrtimer.c에서 찾을 수 있다.

void linsched_run_sim( int sim_ticks );

마지막으로 시뮬레이션 결과는 목록 3에 있는 호출을 통해 볼 수 있다. 이러한 호출은 각각 개별 태스크 통계와 그룹 통계를 표시한다.

	
void linsched_print_task_stats( void );
void linsched_print_group_stats( void );

자세히 분석하기 위해 다음 함수를 사용하여 태스크의 프로세서 ID를 기반으로 태스크를 확인할 수도 있다.

struct task_struct *linsched_get_task( int task_id );

태스크 구조를 사용하여 태스크에 필요한 전체 실행 시간(task_exec_time(task)으로)과 실행되지 않고 소비된 시간(task->sched_info.run_delay) 및 스케줄러가 태스크를 호출한 횟수(task->sched_info.pcount)를 확인할 수 있다.

이 짧은 목록에서 LinSched가 스케줄링 시나리오를 구성하는 데 유용한 API를 제공한다는 사실을 확인할 수 있다. 또한, 이러한 함수를 반복해서 수행하는 것도 가능하며 따라서 일단 시나리오를 시작하여 완료하면 태스크를 새로 추가할 수 있으며 linsched_run_sim을 추가로 호출하여 시뮬레이션을 계속 수행할 수도 있다. 이러한 기능을 통해 반복 가능한 동적 스케줄링 시나리오를 구성할 수 있다.

위로

LinSched에 대한 실험

이제까지 LinSched의 시뮬레이션 엔진 API를 살펴보았으므로 작동 중인 LinSched를 살펴보도록 하자. 목록 4에 있는 예제에서는 LinSched의 basic_test 프레임워크를 사용하여 시나리오를 새로 추가했다. 이 프레임워크에서는 전달되는 두 번째 인수가 사용할 토폴로지가 된다. 이 프레임워크에는 사용 가능한 모든 옵션을 통해 프레임워크에서 실행되는 다양한 토폴로지를 지원하는 topo_db가 존재한다. 정의된 토폴로지를 사용하여 linsched_init를 호출함으로써 이 프로세서 토폴로지에 필요한 환경을 초기화한다. 그런 다음, 세 가지 범주로 11개의 태스크를 작성한다. 첫 번째 5개 태스크는 프로세서에 결부된 태스크(busy 시간 90%, sleep 시간 10%)를 에뮬레이션하는 간단한 create_tasks 함수를 사용하여 작성한다. 그런 다음, 입/출력(I/O)에 결부된 태스크(busy 시간 10%, sleep 시간 90%)를 5개 작성한다. 마지막으로 linsched_create_RTrr_task를 사용하여 busy 시간이 100%이고 우선순위가 90인 실시간 태스크를 작성한다. 그 후에 linssched_run_sim을 호출하여 시뮬레이터를 시작하고 linsched_print_task_stats를 사용하여 결과를 표시한다.

참고: 이 예제에서는 표준 CFS(linsched_run_sim을 사용하여 schedule()을 통해 호출됨)를 사용한다.

	
void new_test(int argc, char **argv)
{
  int count, mask;
  struct linsched_topology topo;
  int type = parse_topology(argv[2]);

  topo = topo_db[type];

  // Allow all tasks to use any processor.
  mask = (1 << count) - 1;

  // Initialize the topology as provided by the script interpreter
  linsched_init(&topo);

  // Create five processor-bound tasks (sleep 10, busy 90)
  create_tasks(5, mask, 10, 90);

  // Create five I/O-bound tasks (sleep 90, busy 10)
  create_tasks(5, mask, 90, 10);

  // Create a busy real-time round-robin task with a priority of 90
  linsched_create_RTrr_task( linsched_create_sleep_run(0,100), 90 );

  // Run the simulation
  linsched_run_sim(TEST_TICKS);

  // Emit the task statistics
  linsched_print_task_stats();

  return;
}

이 시나리오를 실행하면 실행 중에 있는 태스크마다 다양한 결과가 출력된다. 예를 들면, 목록 5에서는 목록 4에 있는 시나리오를 싱글 프로세서 토폴로지에서 실행한 결과를 확인할 수 있다. 이 결과에는 태스크 ID로 번호가 지정된 태스크 목록, 태스크의 전체 실행 시간(틱), 실행을 위해 태스크가 대기한 시간 및 태스크가 호출된 횟수가 표시되어 있다. API를 통해 태스크를 종료할 수 있지만, 이러한 태스크는 결코 종료되지 않는다.

이 시나리오에서는 첫 번째 5개 태스크가 busy 태스크이고 sleep 시간은 10%이다. 두 번째 5개 태스크는 대부분이 sleep 시간이며 busy 시간은 10%이다. 마지막 태스크는 실시간 태스크이며 busy 시간이 100%이다. 표시된 바와 같이 실시간 태스크는 싱글 프로세서에 대한 LinSched의 결과를 수신하며 단지 61번만 호출되었다. 이 결과를 프로세서가 상당히 적었을 때 대략 세 번 호출된 비busy 태스크 및 busy 태스크와 비교하자. 또한, 이 스케줄러는 busy 및 비busy 태스크를 동등하게 처리하여 이 두 가지 태스크에 거의 동일한 프로세서 액세스를 제공한다.

	
Task id =  1, exec_time =   305000000, run_delay = 59659000000, pcount = 156
Task id =  2, exec_time =   302000000, run_delay = 58680000000, pcount = 154
Task id =  3, exec_time =   304000000, run_delay = 58708000000, pcount = 155
Task id =  4, exec_time =   304000000, run_delay = 58708000000, pcount = 155
Task id =  5, exec_time =   304000000, run_delay = 58708000000, pcount = 155
Task id =  6, exec_time =   296000000, run_delay = 56118000000, pcount = 177
Task id =  7, exec_time =   296000000, run_delay = 56118000000, pcount = 177
Task id =  8, exec_time =   296000000, run_delay = 56118000000, pcount = 177
Task id =  9, exec_time =   296000000, run_delay = 56118000000, pcount = 177
Task id = 10, exec_time =   296000000, run_delay = 56118000000, pcount = 177
Task id = 11, exec_time = 57001000000, run_delay =  2998000000, pcount = 61

이제 목록 4에 있는 동일한 테스트를 네 개의 소켓으로 구성된 쿼드 코어 토폴로지(16개의 논리 프로세서)에서 수행한 결과를 살펴보도록 하자. 각 태스크에는 자체 논리 프로세서가 있을 수 있으므로 태스크는 주어진 동일한 테스트 기간 동안 상당히 더 많은 프로세서 시간을 할당 받게 된다. busy 및 비busy 태스크가 동일한 횟수로 호출된다고 하더라도 busy 태스크와 비교했을 때 비busy 태스크의 실행 시간은 10%에 불과하다. 이러한 차이점은 sleep/busy 구성(busy 태스크는 90틱 동안 실행하지만 비busy 태스크는 10틱 동안 실행함)의 결과이다. 또한, 흥미로운 사실은 실시간 태스크는 결코 일시적으로 정지하지 않으며 해당 프로세서에서 다시 스케줄링되지 않기 때문에 일단 호출되면 테스트 기간 동안 계속 실행하게 된다. 목록 6에는 해당 테스트가 표시되어 있다.

	
Task id =  1, exec_time = 54000000000, run_delay = 0, pcount = 601
Task id =  2, exec_time = 54000156250, run_delay = 0, pcount = 600
Task id =  3, exec_time = 54000281250, run_delay = 0, pcount = 600
Task id =  4, exec_time = 54000406250, run_delay = 0, pcount = 600
Task id =  5, exec_time = 54000031250, run_delay = 0, pcount = 600
Task id =  6, exec_time =  6000187500, run_delay = 0, pcount = 600
Task id =  7, exec_time =  6000312500, run_delay = 0, pcount = 600
Task id =  8, exec_time =  6000437500, run_delay = 0, pcount = 600
Task id =  9, exec_time =  6000062500, run_delay = 0, pcount = 600
Task id = 10, exec_time =  6000218750, run_delay = 0, pcount = 600
Task id = 11, exec_time = 59999343750, run_delay = 0, pcount = 1

LinSched로부터 표시되는 데이터를 시각화할 수도 있다. 결과를 그래픽으로 시각화하는 예제를 하나 더 살펴보도록 하자. 목록 7에 있는 예제에서는 nice 값의 범위가 -20에서 19인 태스크를 40개 작성한다. 태스크의 nice 값으로 태스크의 우선순위를 변경한다는 사실을 상기하자(여기서 -20은 가장 높은 우선순위이며 20은 가장 낮은 우선순위임). 정상 태스크 스케줄링에서는 태스크가 nice 값에 비례하여 프로세서를 할당 받는다.

	
void new_test(int argc, char **argv)
{
  int count, mask, i;
  struct linsched_topology topo;
  int type = parse_topology(argv[2]);

  topo = topo_db[type];

  // Allow all tasks to use any processor.
  mask = (1 << count) - 1;

  // Initialize the topology as provided by the script interpreter
  linsched_init(&topo);

  for (i = 0 ; i < 40 ; i++) {
    linsched_create_normal_task( linsched_create_sleep_run(0,100), i-20 );
  }

  // Run the simulation
  linsched_run_sim(TEST_TICKS*10);

  // Emit the task statistics
  linsched_print_task_stats();

  return;
}

싱글 프로세서 토폴로지에서 이 애플리케이션을 테스트한 결과가 그림 2에 표시되어 있다. 표시된 바와 같이 우선순위가 높은 태스크는 프로세서를 많이 할당 받는데 반해서 우선순위가 낮은 태스크가 받게 되는 프로세서 량은 기하급수적으로 낮아진다. nice 값 -20인 우선순위가 높은 태스크는 틱을 1200억 개 할당 받는 반면에 nice 값이 19인 우선순위가 낮은 태스크는 틱을 2100만 개 할당 받는다.

위로

스케줄링 시각화를 위한 기타 옵션

LinSched의 사용자 공간 스케줄러 시뮬레이션 기능이 우수하긴 하지만, 커널 스케줄링과 기타 활동을 시각화하려면 다른 도구가 필요하다. LTT(Linux Trace Toolkit)는 시스템 이벤트를 정교하게 카탈로그화하여 Linux 커널의 내부 조작을 시각화한다. 이 프로젝트는 LTTng(LTT next generation)로 진보되었다. LTTng는 커널의 조작을 그래픽이나 텍스트로 시각화할 수 있는 사용자 공간 도구를 제공한다. 또한, 커널과 사용자 공간에서 추적을 수집하는 결합된 추적 이외에 사용자 공간 추적을 위해 이 도구를 사용할 수도 있다. 자세한 정보는 참고자료 섹션을 확인하도록 한다.

위로

추가 주제

이 짧은 기사를 통해 사용자 공간에서 Linux 스케줄러를 시뮬레이션한 결과 값을 확인할 수 있다. LinSched에 대한 작업을 통해 사용자 공간 시뮬레이션과 실제 커널 기반 스케줄링은 서로 아주 잘 연관되며 따라서 이러한 접근 방식이 프로덕션 과정에서 스케줄러의 작동을 예측하는 데 유용하다는 사실을 확인할 수 있다. 또한, 흥미로운 점은 LinSched가 사용하는 접근 방식이다. 사용자 공간에서 스케줄링을 완료할 수 있는 프레임워크를 새로 빌드하는 대신에 LinSched는 플랫폼을 에뮬레이션하는 데 필요한 랩퍼와 더불어 Linux 커널 코드를 사용한다. 따라서 사용자 공간에서 스케줄러의 유효성이 검증되면 이 스케줄러를 커널로 마이그레이션하여 사용하는 것은 매우 간단하다.

스케줄러 시뮬레이션과 시각화에 유용한 기타 도구와 기술 이외에 LinSched와 관련된 자세한 정보는 참고자료를 확인한다.

참고자료

교육

• Linux 스케줄러 시뮬레이터인 LinSched는 Linux 스케줄링 서브시스템을 호스트하는 사용자 공간 애플리케이션이다. LinSched는 Linux 스케줄링 정책의 작동을 분석하는 데 매우 유용한 도구이다. 또한, LinSched를 위한 git 저장소인 github에서 온라인으로 최신 소스를 확인할 수 있다.
  
  
• LinSched의 세부사항을 자세히 배우기 위한 최상의 방법 중 하나는 LinSched: The Linux Scheduler Simulator라는 제목으로 작성된 짧은 LinSched 백서를 학습하는 것이다. 이 백서에는 샘플 사용법과 워크로드 시뮬레이션 이외에 LinSched에 대한 개요가 자세하게 기술되어 있다.
  
  
• Linux 커널 2.6의 개발 초기에 기존의 복잡한 스케줄러를 대체하기 위해 새로운 스케줄러를 도입했다. 이 스케줄러는 스케줄링할 태스크 수와 관계없이 일정한 시간으로 작동했기 때문에 O(1) 스케줄러라고 불렀다. Inside the Linux Scheduler(developerWorks, 2006년 6월)에서 이 스케줄러에 관해 자세히 배울 수 있다.
  
  
• O(1) 스케줄러 다음에는 CFS가 도입되어 Linux 커널에서 채택되었다. CFS는 모든 프로세스에는 사용 가능한 프로세서 양이 공평하게 주어져야 한다는 생각에 기반을 두고 있다. 이 기사에서 제공한 예제에서 이러한 공평성을 확인할 수 있으며 여기에서는 모든 프로세스(심지어 우선순위가 가장 낮은 경우에도)에 프로세서에 액세스할 수 있는 권한이 주어진다. Inside the Linux 2.6 Completely Fair Scheduler (developerWorks, 2009년 12월)에서 CFS에 관한 자세한 정보를 배울 수 있다.
  
  
• LTTng(Linux Trace Toolkit next generation)는 커널과 사용자 공간 활동을 추적할 수 있는 사용자 공간 시각화 기능을 제공한다. 이 도구는 시스템의 작동을 이해하는 데 유용하며 성능상의 문제점과 소프트웨어 문제점을 디버그하는 데 도움이 된다. 또 다른 유용한 사이트는 Distributed Multi-Core Tracing Research Project이며 여기에서는 최소한의 오버헤드로 멀티 코어 시스템을 추적하는 데 필요한 기술과 알고리즘을 개발한다.
  
  
• Linux 커널에서 구현되는 이러한 알고리즘을 포함하여 스케줄링에 관해 자세히 배우려면 Wikipedia에 있는 Scheduling(computing) 페이지를 확인한다. 이 부분에는 주요 운영 체제의 스케줄러가 간단히 요약되어 있을 뿐만 아니라 FIFO와 라운드 로빈 스케줄링이 다루어져 있다.
  
  
• 리눅스에서는 수백 개의 기술자료 목록과 함께, Linux 개발자와 관리자를 위한 다양한 다운로드, 토론 포럼 및 다른 참고자료를 찾을 수 있다.
  
  
• developerWorks 기술 행사 및 웹 캐스트를 통해 다양한 IBM 제품 및 IT 산업 주제에 대한 최신 정보를 얻을 수 있다.
  
  
• 무료 developerWorks Live! briefing을 통해 최신 IBM 제품 및 도구에 대한 정보뿐만 아니라 IT 업계의 최신 경향까지도 빠르게 확인할 수 있다.
  
  
• developerWorks on-demand demos에서는 입문자를 위한 제품 설치 및 설정부터 숙련된 개발자를 위한 고급 기능까지 망라된 다양한 데모를 제공한다.
  
  
• Twitter의 developerWorks를 팔로우(follow)하거나 developerWorks에 대한 Linux 트윗(tweet)의 피드를 구독하자.
  
  

제품 및 기술 얻기

• 자신에게 가장 적합한 방법으로 IBM 제품을 평가해 보자. 시험판 제품을 다운로드하거나 온라인으로 제품을 사용해 보거나 클라우드 환경에서 제품을 사용하거나 SOA Sandbox에서 SOA(Service Oriented Architecture)를 효과적으로 구현하는 방법을 배울 수 있다.
  
  

토론

• My developerWorks 커뮤니티에 참여하자. 개발자가 운영하고 있는 블로그, 포럼, 그룹 및 위키를 살펴보면서 다른 developerWorks 사용자와 의견을 나눌 수 있다.
  
  

필자소개

M. Tim Jones는 임베디드 펌웨어 아키텍트이자 Artificial Intelligence: A Systems Approach, GNU/Linux Application Programming(2판이 나왔다), AI Application Programming(2판이 나왔다), BSD Sockets Programming from a Multilanguage Perspective의 저자이기도 하다. Jones의 공학 배경은 정지 위성을 위한 커널 개발에서 시작해 임베디드 시스템 아키텍처와 네트워크 프로토콜 개발에 이르기까지 다양한 분야를 아우른다. Jones는 콜로라도 주, 롱몬트 소재 Emulex 사에서 컨설턴트 엔지니어로 활약한다.

아티클 순위

의견

위로

목차

• LinSched 소개
• LinSched의 기원
• LinSched 아키텍처
• LinSched 설치
• LinSched API
• LinSched에 대한 실험
• 스케줄링 시각화를 위한 기타 옵션
• 추가 주제
• 참고자료
• 필자소개
• 의견