mm:rewrite vmap layer Jan 4, 2009

2.6.28에서 Memory Scalability를 위해 추가된 split lru말고도 우리가 주목해야 할 patch는 vmap이다. Nick이 제안한 이 패치가 mm tree에서 드디어 mainline으로 merge되었다.

Nick이 주목한 문제는 vmalloc의 scalability이다. 정확하게는 vmap의 scalability이다. 더 정확하게는 vunmap의 scalability이다. vmalloc으로 할당한 주소를 해지하는 이 함수는 당연히 IPI를 통한 TLB flush를 해야만 하기 때문이다. 이는 processor가 많아지면 많아질 수록 overhead가 커질 수 밖에 없다. 그리고 vmalloc의 address space를 관리하는 자료구조가 linked list이고 global lock 하나였다는 것이다. Scalability에 치명적일 수 밖이 없는 구조였다.

세상에 multicore가 일반화되며 부각된 문제이다. 그러므로 Nick은 먼저 linked list를 없애기 위하여 red-block tree로 대치하였다. 다음 global lock을 없애기 위하여 작은 주소 공간을 각 per_cpu로 cache하여 관리하게끔 바꾸었다. per_cpu list는 32bit에서는 32개, 64bit에서는 64개까지 page를 cache할 수 있다.

마지막으로 lazy tlb flush를 제안하였다. 해지된 vmalloc의 address space는 시스템으로 회수되기 때문에 다시 할당되기 전까지는 사용될 수 없다. 결국, 어떤 code들도 이미 해지된 그 주소를 다시 사용할 수 없다(Bug가 아니고서야 :)). 하지만 우리가 보장해줘야 할 것은 다시 그 주소 영역이 할당되는 경우이다. 이때는 반드시 TLB consistency를 보장해줘야만 한다. 그러므로 Nick은 해지된 영역들을 충분히 쌓아두었다가 한번에 flush 하자는 것이다. 아이디어가 간단하고 이미 시스템 프로그래밍의 여러 부분에서 사용되고 있는 방법인 반면에, Linux core를 속속들이 이해하지 못하는 경우 생각할 수 없는 좋은 아이디어라고 생각한다. 좀 인위적인 테스트이긴 하지만 대략 기존보다 25배나 빨라진 것을 알 수 있다.

아직 많이 미진하지만 분석 문서를 첨부한다.
이 문서는 앞으로 보다 세심히 업데이트 할 것이다.

vmalloc 문서

mm:rewrite vmap layer

[PATCH 0/2] pdflush fix and enhancement Jan 2, 2009

http://lkml.org/lkml/2008/12/30/245

Novell의 Peter W Morreale 는 현재 min, max가 2와 8로 고정되어 있는 pdflush의 갯수를 admin이 fine tuning할 수 있게끔 패치를 올렸다. 또한 SMP 시스템에서 동기화 문제로 인하여 pdflush 쓰레드의 갯수가 시스템이 정해놓은 boundary를 넘어가는 경우도 패치하였다. (이것이 point는 아니다.)

패치 자체는 굉장히 간단하다. 반면, 많은 것을 생각하고 고려했던 패치이다. Andi의 "그러한 knob들을 늘려가는 것은 결국 커널이 self-tuning을 포기하는 것이기 때문에 rationale이 명확해야 한다"는 comment에서 시작하여 굉장히 길게 토론되었다.

이 쓰레드의 포인트는 현재 pdflush 생성과 소멸의 시점에 문제이다. 현재 구현은 단순히 얼마나 pdflush 쓰레드들이 바쁘냐, 한가하냐만을 가지고 pdflush 스스로 자신의 갯수를 늘리거나 줄인다. 하지만 정말 중요한 문제는 pdflush의 쓰레드의 boudary magic value들, 즉 2와 8 또는 one pass 에 writeout 할 dirty page들의 갯수인 MAX_WRITEBACK_PAGES(1K) 값들이 문제이다. 이런 static magic value가 모든 경우를 cover할 수 없는 것이다. 컴퓨터 시스템은 다양한 block device들을 가지고 있다. RAID, IDE disk, SSD 등 .. 또한 다양한 device들은 서로 다른 bandwidth를 가지고 있다. 그러므로 500MB/s이 나오는 SSD의 block device에 더 많은 쓰레드를 할당하는 것이 IDE에 하는 것보다 좋지 않겠냐??. 또는 일반적으로 하나의 disk를 가지고 하나의 filesystem을 갖는 small system에서 8개의 쓰레드를 경쟁시키는 것이 과연 좋겠냐는 것이다. 반대로 많은 block device와 file system을 갖는 large server 환경에서 pdflush 쓰레드를 8개로 제한을 하는 것이 효율적일까?? pdflush는 block device들의 특성을 전혀 반영하지 못하고 있다.

또 다른 문제는 pdflush의 worker function인 background_writeout에서 발생한다. 이 함수는 filesystem을 traverse하며 super block들을 역순으로 writeout하기 시작한다. 즉 file system들의 dirty page들의 불균형이 올 수 있다는 것이다. 가장 마지막의 filesystem의 dirty page들이 우선적으로 고려되기 때문이다.

그러므로 이번에 올린 패치와는 무관하게 pdflush의 근본적인 redesign이 필요하다는 것이다.

EOF of 2008 Dec 31, 2008

한해, 한해는 정말 바쁘기만 하다.

늘상, 집, 회사만을 오가면서도 이렇게 한해가 바쁠 수 있었던 것은
지키려는 것들이 늘어만 가기 때문일 것이다. 지켜야 할 것들과 미련한 소유욕이 한해 동안 여러 득실을 가져다 주었다.

여러 기억에 남을 일들이 있는 한해지만 무엇보다 인상깊었던 일은 다시 기타를 잡았다는 것일 것이다. 손 놓은 지 거의 5년 만에 다시 잡은 기타다. 예전 연주했던 곡과 악보를 마주할 때는 그 추억들에 혼자 센치해지곤 했다. 이번에 다시 잡은 기타는 다시 놓지 않게 될 것 같다. 녀석들과 소주 한잔 해야 하는데... 저울이 기울어지지가 않으니.

여러 사람들이 떠나고, 새로 들어오고 했던 한 해이기도 하다. 눈에서 멀어진 사람도 있고 마음에서 멀어진 사람도 있고... 나는 언제가부터 과감히 금을 긋기 시작했다. 말이란 것이 비뚤어지기 시작하면 결국 그 속내가 드러나기 마련이다. 오히려 있는 듯, 없는 듯, 자신을 과장해서 낮추거나 광대가 되는 편이 더 낫다. 물론 오해가 있는 경우도 있지만, 한번 소원해진 관계는 한계가 있기 때문이다. 이러한 일들이 점점 나를 가두는 일일지언정.

하고자 하는 일에 초석을 세운 한해 이기도 하다. 그 일에 대한 두려움 보다는 해나가과는 과정이 재밌기만 하다. 아직 갈길이 멀지만 언제나처럼 시간은 부족하다. 호기심이 절정에 달한 이 시기가 매우 중요하다. 내년 한 해는 올해보다 더 중요한 시기가 될 것이다.

언제나 드는 생각이지만 Zero Sum 게임이다. 얻는 것이 있으면 잃는 것도 있는 것이 당연지사. 귀차니즘에 편승한 그러한 생각들이 가끔은 삶을 윤택하게 하기도 한다.

끝으로, 감정표현이 서투른 탓에 항상 잘해주지 못해도, 끝까지 참아주고 믿어주는 이 친구에게도 감사의 말을 전한다.

Adios 2008

꼬랑지)

Greenmail은 항상 불평이다. 내가 연주하는 이 곡이 맘에 안든다는 것이다.
사람을 우울하게 만든다고. 그래도 가끔 콧노래로 따라 부르는 것을 보면 그렇게 맘에 들지 않는 것도 아닌가 보다.

[PATCH] cpuset,mm: fix allocating page cache/slab object on the unallowed node when memory spread is set

http://lists-archives.org/linux-kernel/19778435-cpuset-mm-fix-allocating-page-cache-slab-object-on-the-unallowed-node-when-memory-spread-is-set.html

크리스마스 징검다리 연휴가 들어가기전 report되었던 버그이다.
Miao라는 중국 fujitsu 개발자이다.
문제는 memory_spread_page가 set되어 cupset's mem이 변경되었을 때 slab이 바로 그 사항을 반영하지 못하여 old mem에서 메모리를 할당한다는 것이다.

것도 문제이지만 더 큰 문제는 해당 패치가 kernel's hot path에서 polling하는 루틴을 넣었다는 것이다. 이에 대해 다른 개발자들은 모라고 할 것인지 그 추이를 지켜보고 있었는데 아니나 다를까 Andrew는 다음과 같은 문제를 제기했다.

c) These are two of the kernel's hottest code paths. We really
really really really don't want to be polling for some dopey
userspace admin change on each call to __cache_alloc()!

d) How does slub handle this problem?

C는 barrios와 같은 의견이고 D에 대해 Christoph가 모라고 답변을 할지 기대된다. 그 추이를 지켜보자.

SLQB - and then there were four Dec 28, 2008

http://lwn.net/Articles/311502/

요즘 관심을 가지고 있는 것이 SLQB이다. SLQB는 기억으론 5개월 전쯤 이미 한번 RFC가 올라왔었다. 하지만 그 때 mm guys들은 별다른 반응을 보이지 않았었다. 그 때는 이미 SLUB에 대해 막판 다듬기가 한참이었던 것으로 기억한다. 그래서 다들 SLUB에 신경을 곤두세우고 있어서 일지도 모르겠다. 어쨌든 Nick은 두번째 제안을 해왔다.

SLQB의 특징은 구조가 굉장히 간단하면서 기존의 다른 allocator들에 크게 뒤지지 않는다. 그 이유는 per-CPU 형태를 취하고 있기 때문에 lock이 많이 줄어들었다. 또한 SLQB는 가능한한 high order allocation들을 피하려고 한다. high order allocation은 memory pressure의 가장 큰 범인이기도 하다. 그러므로 단편화를 줄이기 위해서라도 one order allocation이 바람직하다.

SLQB는 freelist, rlist, remote_free list로 object들의 list를 나누어 관리한다. 그 이유는 cache bouncing을 줄이기 위함이다. long running object들은 할당한 CPU가 아닌 다른 CPU에 의해서 해지될 가능성이 높다. 그러므로 cache line bouncing을 줄이기 위해 해지되는 object들은 처음 할당한 CPU로 옮겨주는 작업을 하여 cache hit을 최대한 높이겠다는 의지인데, 과연 long running한 object들이 할당된 CPU의 cache에 아직 남아 있을까?? 좀더 생각해 볼 필요가 있다.

SLQB의 전반적인 성능은 slab에 비하여 다소 떨어진다. 그 이유는 명확하지 않다. object들을 array 형태가 아닌 list 형태로 구현하면서 object cacheline layout의 변화에 기인한 것일 수도 있다. 어쨌든 Nick은 계속해서 이 allocator의 성능을 높일 것이며 barrios 또한 계속해서 이 코드에 대해 review 할 것이다. 코드에 사소한 bug와 naive한 code가 있으나 review가 다소 늦어서 이번에 comment하진 않을 것이다.

SLQB를 테스트 하는 동안 기존의 mainline kernel에서 bug가 발견되었다. SLQB를 사용했을 때 그 문제가 나타나게 된 원인은 SLQB는 object안에 metadata를 함께 관리하고 있기 때문이다. 그러므로 object의 크기 이상으로 메모리를 write하였을 경우, object list가 붕괴된다. 그 문제는 POISON을 가지고 알 수 있다. 바로 mainline에 report하려 했으나, rc 버젼이었고 SLQB 또한 review가 끝나지 않은 상태라서 보고 하지 않았다. 2.6.28이 나왔으니 SLQB를 시험해보고 문제가 동일하게 다시 발생한다면 그 때 보고할 예정이다.

꼬랑지)
시간이 되면 POISON과 RED_ZONE도 문서에 추가하고 싶긴한데.. 사람들이 일반적으로 잘 모르는 기능이라.. 시간이 될지 모르겠다. 다른 할일이 많아..


끝으로 간단히 분석한 문서를 첨부한다.

SLQB 문서

The 2.6.28 kernel is out Dec 25, 2008

http://lwn.net/Articles/312786/

2.6.28이 release 되었다. 몇가지 살펴봐야 할 주요한 패치들이 있다.
시간이 되고 정리가 되면 그 때 다시 살펴보기로 한다.

Linus의 말이 재미있다. 크리스마스 답게 산타의 선물에 빗댄 2.6.28 release.
과연 아이들이 그 선물을 좋아할까? ^^

각설하고 이번 2.6.28의 릴리즈는 나에게는 그 이상의 의미가 있다.
한동안 작업했던 메모리 회수의 성능 향상을 위한 split LRU가 mainline에 정식으로 merge되었다.
그로 인해 몇건의 mainline contribution이 더 추가되었다.

작은 fix또한 Signed-off-by를 추가해준 Rik에게 감사의 마음을 전한다.

Vals No. 4 Op. 8 Dec 22, 2008

근래 연습중인 곡이다.
망고레의 왈츠 4번.

2003년 이었던 것으로 기억한다. 후배 한 녀석이 오랫만에 찾은 동아리방에서 연주하고
있던 곡이 이 곡 이었다. 그 전까지는 사실 별로 연주하고 싶은 맘이 들던 곡은 아니었다.
딱히, 그 후배가 이 곡을 연습하게 해준 동기는 아니더라도,
나도 이 곡을 연주 할 수 있게 구나 하는 정도의 동기는 유발해준 것이 사실이다.

이 곡의 하이라이트는 중간의 연속되는 아르페지오와 함께 상승 베이스,
다시 하강 베이스 바하의 대위법은 아니지만 서정적이면서도 멋있는 곡의
분위기를 살려준다.

특히 마지막 부분에 고조감을 느끼게 연주하여 끝을 맺는 부분을 잘 살려서 연주해야 한다.

아래 동영상은 실제 CD 연주보다는 다소 천천히 친 감이 있다.
망고레 연주의 대가 러쎌의 연주를 감상할 수 있는 여유가 있을 때 이 곳을 들를 수 있기를.

- 2008년 두번째 눈이 내리던 날 -