2011 Realtime Minisummit

한동안 엄청나게 뜸했었나?

IBrix 녀석이 이슈도 많고, 귀찮기도 한데다, LWN 도 어차피 일주일지나면 공개되는녀석이라

구지 이렇게할  필요가 있나 싶어 패스하고 있었는데, 아무래도 나태해지는것 같아서,

다시 시작해 보려고 한다.

일단 2011년 RT Minisummit 이 10월 22일 프라하 ( Prague 라는데 영어식이래 )

에서 열렸다고 한다. - 3일간 개최하며 13번째나 된다고 하네...

( 기사 본문 : http://lwn.net/Articles/464180/ 일주일 후 열람 가능 )

일종의 Realtime (이하 RT) 개발자들 관련하여 워크샵처럼 소규모로 모여 회의하는건가본데,

회의 내용은 다음과 같다.

1. Per-CPU data
2. Software interrupts
3. Upstreaming
4. The Future

이렇게 네가지라는데, 하나하나 살펴보도록 하자. (나도 얕은지식으로 덤벼드는거라ㅠㅠ)

1. Per-CPU data

일단 기사 내용을 보자면,

애초에, 리얼타임 선점 패치에 대한 가장 큰 도전중 하나는,

데이터를 각 CPU 당 처리하도록 하는것에 있었다는 것이고,

per-cpu 변수 이용을 매우 좋아하는 처리량지향(throughput-oriented) 개발자들로 인해,

Lockless (락없는) 데이타 엑세스에 대한 개선과 코드의 확장성을

향상시키는 성과를 이루어 냈지만,

per-CPU data 는 기본적으로 선점방식을 쓰지 않는걸 요구하는데 반해,

이 리얼타임 패치셋들은 Direct 카운터들을 실행 할 수 있도록 노력함으로써,

일종의 높은 처리량과 낮은 지연시간에 대한 목표치가 호환되지 않는등의

모순이 생겨 골치아프다는 얘기이다.

이런 부분에 관련하여 최근엔 get_cpu_var 라는 통합적 API 대신,

더 잘개 쪼개진 this_cpu_read 나 this_cpu_write 등의 새로운

펑션셋을 적용해 속도를 높이려고 했으나, 몇가지 골치거리가 발생했단다.

우선 이녀석들은 선점방식을 사용하지도 않으면서 Locking 매카니즘을 내포하고 있지 않다는점..

이로 인해, this_cpu_read ()에서 읽어와 반환된 값이 호출하는 스레드가, 실제로 그것이 해당하는 어떤 순간에 읽어진 값이 아닐 수도 있다는 것이고,

다른 외부의 선점기능의 비활성화 없이 이 this_cpu_read 후 this_cpu_write 가

동작하게 된다면, 읽어온 CPU 값과는 다른 값을 쓰게 될 수도 있어,

자료구조가 달라지게 된다는 점이다.

아무튼 이 this_cpu 관련 함수들이 디버깅도 어렵고, Ingo Molnar 의 주장에 따르면,

API 가 문제를 갖고있는게 아니라 아직 불완전할 뿐이라고 하는걸 봐선,

이것들에 대한 엄청난 토론이 이루어 졌을거라고 짐작할 수 있다.

먼저 이 함수자체가 갖고 있는 모호성 ( this 라는게 대체 뭘나타내냐? 등등 )

을 개선하기 위해, 이름을 바꾸자는 얘기도 있었고, 마이그래이션을 막거나,

선점방식들을 사용해서 Local Lock 형식을 적용하자는 얘기도 있었다.

한편, 선점방식을 해제시키는 방법보다 프로세서간의 이전(마이그레이션) 을

우선순위별로 잠금보호를 구현하자는 획기적인 의견도 나온다.

현재는 기존 선점방식보다 우선순위를 통한 CPU 간 데이타 핸들링을 사용했을때

발생 할 수 있는 점에 대해서 신중히 검토중인가보다.

앞으로 많은 개선을 위한 토론들이 꾸준히 있을것 같다. +.,+

2. Software interrupts

CPU 에서 지연시간을 낮춘다고 해서 리얼타임의 컴퓨팅이 이루어졌다고 할 수 없다.

요즘엔 네트워크나 디스크등에 대한 인터럽트도 중요시 되는 시기인 게다..

오랜기간 원래 리얼타임 선점방식의 패치셋들은 별도의 스레드를 이용하여 softirq를

분할하여 처리하였는데, 최근 이 분할된 부분을 제거하였다고 하며,(하나로합친듯)

장기적으론 Threaded 인터럽트 핸들러로 대체할 예정이라고 한다.

이 과정에서 Storage 서브시스템(SCSI 등등) 또한 쓰레드화된 인터럽트 핸들러로

전환시켜 복잡한 SCSI 오류복구 코드를 간편화 하는게 어떻냐는 내용도 거론됬단다.

이부분은 사실 Softirq 가 리얼타임에서 얼마나 중요하게 고려되는지를 나타내는 부분으로,

커널상에서 trylock 이 흔히 이루어 지는 것 때문에, 코드가 잠금을 얻으려다 실패할 경우,

IRQ 핸들러는 다음 SoftIRQ 에서 재시도 할 것으로 판단하여, Interrunpt 되고,

단지 핸들러가 스레드로 실행될때의 얘기지만, 이것은 가장 높은 우선순위를 갖게 될

가능성이 높아져 바로 다시 실행될 수도 있을 것이다.

그러나, 이런 계속된 루프는 결국 스레드의 스케쥴링을 방해하여 livelock 상황으로

이끌 수 도 있어 해결이 필요하나, 영향받는 코드들에대한

재구성이 필요로 할 수 도 있어 논란이 계속 되고 있단다. 아 복잡해 ㅡ,.ㅡ::

무튼 개인적으론 softirq 의

3.Upstream

이부분또한 논쟁이 많이 있었나본데, 사실 오리지날 선점방식-RT 패치는

약 7년전에 발표됐었고, 그동안 메인라인의 트리에 포함되지 않고 개발이 되어왔나보다.

아무튼 시간이 지남에 따라 막대한 코드들이 메인라인 트리로 이동하였으나,

약 300개정도의 패치는 아직 바깥으로 나가있고, 이런 부분에 대한 문제들도

엄청 골치아프겠지.. 사실 이쪽 부분은 개발에 대한 엔트로피들과 관련되어 있는

문제라 개발경험이 없는 나로써는 좀 이해하기 어려운 부분이라 일단 패스해야할것같다.

아무튼 빠른 패치 및 메인라인 트리를 유지하기 위해서 패치들의 간략화 및

간결성 유지등에대한 노력이 들고, 노력하고 있다는 거~

이놈의 주류는 대체 뭔지 ㅎㅎ

4. The Future

현재의 RT 커널은 완벽히 작업이 다 완료 되어 Merge 된 상태가 아니다.

이들은 꾸준히 개발하고 있고, 다음과 같은 계획들을 추가로 갖고 있다.

* Deadline Scheduling : 이패치의 상태는 "나쁘지 않은" 상황으로 진행되고 있다.
그러나 개발자들이 모두 새로운 것들로 인해 정신을 집중하고 있지 못하며,
새로운 개발자를 선출하여 진행을 계속 할 것으로 보인다.

* CPU isolation : 이것은 Clock Tick 이나 다른 오버헤드 없이 하나 또는 그 이상의 프로세서들을 실행하는 능력이다.이것은 프레드릭이 지속적으로 패치중이고,
많은 것들이 완료되고 있으므로 구지 즉시 Merge 를 하라고 압박할 필요는 없단다.

여기까지가 일단 기사의 내용이고,

기사의 내용을 전부 번역하기보단 관심을 갖고 한번 살펴보기 좋을 정도로만

얘기하였다.

Realtime 컴퓨팅에 대해서 아직 충분한 지식을 갖고 있진 않지만,

요즘 상당히 주목받고 있는 부분인건 사실이고,

앞서 얘기했던 높은 처리량과 매우 낮은 응답시간을 어떻게하면

최대한 제공할 수 있을지에대한 노력은 꾸준히 이루어 지고 있는것 같다.

개인적으로 여기서 또 한가지 중요하다고 생각하는 점은 낮은 응답시간과

높은 처리량뿐만아닌, 지속적인 서비스또한 중요하다고 생각한다.

즉, High Throughput - Low Latency - Continues Service 의 삼위일체가

궁극적으로 이루어 져야 할 목표라고 본다.

아직 일반 커널조차 제대로 파악하지 못한 상태에서 리얼타임은 그림의 떡일뿐이지만,

언젠간 나도 저들 사이에서 미래를 위해 한마디 할 수 있는 날이 오지 않을까? 안오냐? ㅎ