1. 서버 시스템의 구조

1. NUMA(Non-uniform memory access) Architecture

2. 임베디드 시스템(모바일)

1. Big Little 구조

-퍼포먼스의 증가량보다 전력 사용량 증가량이 더 큼, 따라서 Big core, Little core를 나누어 사용

3. 따라서 멀티코어 스케줄링 -> 로드 밸런서

• 공유 메모리 기반 멀티프로세서
• 어떤 프로세스를 어떤 CPU에게 할당해줄지 결정해주는 역할을 로드밸런서가 맡음

1. 글로벌 큐 + 로드 밸런서

1. 하나의 대기 큐에서 모든 CPU들에 할당하는 작전

2. 장점

• Good CPU Utilization
• Fair to all process

3. 단점

• Not scalable(contention for global lock)
• Poor cache locality

2. Per-CPU 큐 + 로드 밸런서

1. CPU별로 별도의 큐를 할당

2. 장점

• Easy to implement
• Scalable ( no contention on ready queue)
• Better cache locality

3. 단점

• Load-imbalance(some CPUs have more process)

4. 밸런싱 하는 시점

1. fork & exec

• 프로세스 생성 시 idlest cpu로 분산 시킴

2. wake up

• 현재 wake-up 한 cpu로 migration 시킴(또는 이전 cpu 유지)

3. idle

• 적당한 Task를 찾은 후 현재 CPU로 migration

4. periodic

• 주기적으로 체크 훌 밸런싱

5. Load Tracking Metric

• 로드 밸런서가 사용하는 로드 값

1. Number of threads

1. 문제점

• 큐1은 높은 우선순위를 갖는 Thread 큐, 큐2는 낮은 우선 순위를 갖는 Thread 큐일때 문제 발생

2. 해결책

• Thread 수가 아닌 스레드의 weights를 이용해서 밸런싱

2. Weights of threads

1. 문제점

• 스레드가 10개가 있는데 1개는 우선순위가 높은 스레드, 나머지는 우선순위가 낮은 스레드일때

2. 해결책

• weights 만 보는 것이 아닌, thread weight 와 CPU Utilization을 함께 이용해 밸런싱
  -> CFS's load

3. CFS load balancer

1. 문제점(멀티스레딩)

• 프로세스 1은 많은 수의 스레드 실행
• 프로세스 2는 1개의 스레드만 실행

결과

• 스레드 기준으로 로드 밸런싱이 되기 때문에 프로세스1 이 프로세스2 보다 많은 시간동안 CPU 사용
  -> 불공평

2. 해결방안

• 리눅스는 group scheduling 기능을 통해 해결(cgroup)
  -> 두 스레드 그룹에 공정하게 분배