Innovators get Linux to boot in 1 second Mar 7, 2010

http://lwn.net/Articles/377507/
http://www.edn.com/article/CA6720353.html

Montavista가 1초 부트를 했다는 기사가 떴다.
자동차 계기판 시스템을 Linux를 사용하여 한 것 같다.

기술내용은 위의 글들로 미루어보아

첫째, 불필요한 커널 옵션 정리, 부트로더에서 redundant한 부분 정리
(임베디드에서 하드웨어가 한번 fix되면 변하지 않는 성질을 응용)

둘째, Linux의 부팅과정 중 필요한 여러 일들을 수행함에 있어 필요한 task들을 로딩하거나
파일들을 읽어오기 위한 Flash와 Memory의 복사 비용을 DMA를 사용하여 줄임.
이때 CPU는 다른 task를 수행함(요즘 CPU는 예전에 비하여 상대적으로 큰 cache를 가지고 있기
때문에 대부분 필요한 일들을 cache에서 hit시켜 위의 여러 작업을 병렬적으로 할 수 있다.)

셋째, 부팅시에 필요한 즉, 사용자에게 마치 모든 작업이 완료되어 당신의 입력을 기다리고
있어요라고 말할만큼의 일을 하기 위해 필요한 application들만을 모아서 ramfs 사용(ramdisk 아님)
으로 생각된다.

기술적으로 별것 아니라고 하면 별것 아닐수도 있지만 한편으로 대단하다 생각하면
대단하기도 하다.
위의 기술들이 upstream에 merge될 수 있느냐, 없느냐가 중요한 것은 아닌 것 같다.
중요한 건 지금 그들은 1초 부트를 하고 있다는 것 뿐이고 다른 사람들은 아직 Linux를
가지고 1초 부트를 하지 못하고 있다는 것이다.

또 여러 사람 고생할게 눈에 불 보듯 선하다.

sys_membarrier() Mar 1, 2010

http://lwn.net/Articles/369567/

최근 membarrier에 대한 system call추가에 관한 논의가 계속되어 왔다.

이 새로운 system call은 Mathieu Desnoyers에 의해 시작되었으며,
자신이 만들고 있는 LTTng tracing toolkit에서 성능을 높이기 위한 목적으로
사용하려고 한다.

Mathieu는 얼마전 Paul과 User-Level RCU library를 만들었었다.
물론 이 library또한 LTTng tracing toolkit에서 사용하기 위해 만들었던 것이다.

User-Level RCU라 하면 가장 먼저 드는 의문이 어떻게 Kernel-Level RCU의
(wait for pre-existing RCU readers to complete) property를 만족시킬
것인가이다. Kernel-Level RCU는 rcu_read_lock의 kernel preemption을 disable하는
특성으로 위의 property를 만족시키고 있다. 하지만 User-Level에서 kernel preemption을
막는다는 것은 ugly한 방법을 사용하지 않고는 가능하지 않다. (일시적으로 task를 제일 높은
priority의 RT task로 변환하면 가능하지만 다른 RT task를 선점하는 좋지 않은 side effect
이 발생한다.)

그리하여 User-Level RCU에서 취한 방법은 thread가 RCU critical section에 있다는
것을 표헌하기 위해 특정 메모리 영역에 변수를 setting하는 것이다.
하지만 이과 같은 approach의 문제는 memory misordering 문제에서 시작된다.
CPU 1에서 실행되고 있는 A 라는 쓰레드가 RCU critical section이 완료되었다는 것을
보장받기 위해 CPU 2에서 실행되는 B 라는 쓰레드는 synchronize_rcu를 호출할 것이다.
하지만 이때 synchronize_rcu는 memory misordering문제로 인하여 A 쓰레드가
RCU critical section에 존재한다는 것을 missing할수 있게 된다. 즉 B가 모든 RCU
critical section이 완료되었다고 판단하였지만 실제로는 쓰레드 A가 RCU critical section
에 남아 있을 수 있다는 것이다. 이는 A가 사용하는 자원이 갑자기 사라질 수 있음을 의미한다.

이 문제는 간단히 rcu_read_lock/unlock에 memory barrier를 두면 해결되는 문제이지만,
일반적으로 RCU reader들은 fast path에 속하기 때문에 간혹 수행되는 slow RCU updater들로
인해 fast path에 성능을 손해봐야 한다는 것은 기본적으로 RCU policy에 적합하지 않다.

이와 같은 문제를 해결하기 위해 Mathieu는 membarrier라는 새로운 system call을 추가하고자 한다.
이 새로운 membarrier를 통해서 기존의 rcu_read_lock/unlock은 Kernel-Level RCU와 마찬가지로
compiler level의 reordering만을 막고(CPU level의 reordering을 막는 것은 아니다), 대신
updater가 동기화를 요구할 때 새로운 system call을 호출하여 reader들의 memory barrier들을
실행하는 것이다. Update의 실행이 적은 RCU의 policy에 잘 만족하는 overhead 분산이다.

이 함수의 초기 구현은 시스템의 모든 CPU에 IPI를 날리고 그 반응으로 각 CPU에서 memory barrier
를 실행하는 것이었다. 하지만 이와 같은 방법은 user space가 모든 CPU에 강제로 interrupt를
날릴수 있는 기회를 제공함으로써 또하나의 DoS attack을 만들수 있는 기회를 제공한다는 문제가 있다.
또 다른 문제점은 실제 membarrier를 호출한 프로세스와 관계없는 CPU들까지(즉, 다른 task들을
수행하고 있는 CPU)까지 쓸데 없이 interrupt을 한다는 것이다. 다른 task가 RT task라면 문제는
더욱 심각해질 것이다. 또 다른 문제는 인터럽트된 프로세서가 sleep mode에 있었다면....
Green IT 하자고 난리인 이 판국에.

이 패치는 많은 lock expert들에 의해 in-depth review가 이루어지며 optimization작업이
진행되어 왔다. 현재 이 system call은 시스템에 모든 CPU를 살펴 caller와 같은
address space를 공유하는 녀석들이 실행되고 있는 CPU들만을 참조하여 IPI를 보내게 된다.
이 방법은 위에서 문제되었던, DoS, RT task performance, Energy Consumption 문제를
해결한다.