오랜만이다. 이렇게 블로깅을 하는 것은.
이유야 여러가지가 있지만 구구절절 말할만한 상황은 아니고.
그동안 mainline에는 재미있는 일이 너무나도 많았다.
그 많은 것을 다 같이 공유하고 싶은 마음이 큰데 시간과 barrios의
게으름이 허락치 않는다. 가장 최근에 벌어지는 이슈에 대해서만 먼저
한번 얘기해보자. (나머지는 차차 기회가 있겠지)
http://lkml.org/lkml/2010/4/12/366
지금 barrios가 가장 관심을 가지고 있는 issue는 direct reclaim의
page write back문제이다. 다들 잘 알고 있겠지만 kernel은 OOM 상황을
막기 위해 시스템의 process들의 귀중한 시간을 훔친다. 즉, 하찮은 커널이
무대의 주인공인 프로세스들의 context에서 프로세스를 위해 일을 하는 것이 아니라,
메모리를 회수하기 위해 귀중한 프로세스의 resource를 것도 많이 사용한다는 것이다.
이 자체가 썩 유쾌하지 못한 상황이긴 하지만 kernel 입장에서는 어쩔수가 없다.
프로세스를 죽이는 것 보다야 낫지 않는가.
어쨌든, 지금 이슈는 이 direct reclaim path에서 stack overflow가
발생한다는 것이다. 이 문제를 제일 먼저 report한 이는 xfs의 maintainer라고
볼 수 있는 Dave Chinner이다.
Depth Size Location (47 entries)
----- ---- --------
0) 7568 16 mempool_alloc_slab+0x16/0x20
1) 7552 144 mempool_alloc+0x65/0x140
2) 7408 96 get_request+0x124/0x370
3) 7312 144 get_request_wait+0x29/0x1b0
4) 7168 96 __make_request+0x9b/0x490
5) 7072 208 generic_make_request+0x3df/0x4d0
6) 6864 80 submit_bio+0x7c/0x100
7) 6784 96 _xfs_buf_ioapply+0x128/0x2c0 [xfs]
....
32) 3184 64 xfs_vm_writepage+0xab/0x160 [xfs]
33) 3120 384 shrink_page_list+0x65e/0x840
34) 2736 528 shrink_zone+0x63f/0xe10
35) 2208 112 do_try_to_free_pages+0xc2/0x3c0
36) 2096 128 try_to_free_pages+0x77/0x80
37) 1968 240 __alloc_pages_nodemask+0x3e4/0x710
38) 1728 48 alloc_pages_current+0x8c/0xe0
39) 1680 16 __get_free_pages+0xe/0x50
40) 1664 48 __pollwait+0xca/0x110
41) 1616 32 unix_poll+0x28/0xc0
42) 1584 16 sock_poll+0x1d/0x20
43) 1568 912 do_select+0x3d6/0x700
44) 656 416 core_sys_select+0x18c/0x2c0
45) 240 112 sys_select+0x4f/0x110
46) 128 128 system_call_fastpath+0x16/0x1b
위의 로그를 살펴보면 direct reclaim path전까지 3.1K정도의
stack이 사용되어졌으며 XFS가 3.5K를 사용하는 것을 볼 수 있다.
다음 block layer와 몇가지 더 하면 금방 8K가 바닥이 나버린다.
XFS가 3.5K를 사용하는 것도 크지만 direct reclaim path만도
대략 1.1K나 사용하고 있다. 불과 함수 몇개가 말이다.
이 report는 또 다른 문제를 언급하고 있다. VM의 reclaim으로 인해
발생하는 I/O와 flusher가 발생시키는 I/O가 섞여 결국 random write가
발생하게 되고 이는 reclaimer와 flusher의 throughput을 떨어뜨리게
될 것이다.
이를 해결하기 위해 Dave가 제안한 것은 direct reclaim path에서
아예 writeback을 하지 말자는것이다. 굉장히 공격적인 방법이다.
그러므로 해당 thread는 현재 74개의 메일들로 토론이 진행되고 있다.
처음 토론이 진행되었던 것은 lumpy reclaim 문제이다.
Mel의 lumpy reclaim은 LRU distance와는 관계없이 특정 상황이 되면
lru list에 있던 페이지들에 물리적으로 근접해 있는 페이지들을 회수하여
big order contiguous page들을 만들어 내는 것이다. 이때 필요에
따라 우리는 dirty page들을 flush해야 하는 상황이 필연적으로 발생한다.
그런데 pageout을 생략하게 되면 그러한 lumpy reclaim이 직접적으로 타격을
받게 되는 것이다.
그래서 Mel과 Kosaki는 stack diet를 시도하고 있고, 반면 그것이 근본적인
해결책이 아니라고 사람들도 있다. barrios도 처음에는 전자의 편에 있었지만
좀더 생각해보니 후자가 더 좋을 것이라고 생각한다. 위의 로그를 보면
direct reclaim path도 stack을 많이 사용하였지만 XFS 또한 많이 사용하였다.
그리고 direct reclaim path전에도 무시하지 못한다.
결국 stack diet를 해서 어느 한 곳을 줄여봐야 모든 곳을 줄이지 못하면 언젠가
다시 이 문제를 만나게 될 것이라고 생각한다(우리는 함수가 nesting되는 경우나
다른 함수들을 통해서 호출되는 경우도 생각해야 한다. 위에서 보는 log의 사용량이
절대 worst case가 될 수 없다는 것이다.) 또한 barrios는 앞으로 reclaim path를
수정할때마다 stack 사용량을 일일이 계산하며(ie, 걱정하며 :)) coding하고 싶지 않다.
그렇다고 direct reclaim path에서 I/O를 하지 않게 되면 우리는 보다 많은
OOM을 만나게 될 것이다. 사실 direct reclaim path에서의 writeback은
process들의 progress를 다소 완화시켜주는 역할도 하기 때문이다.
이 와중 Andrew Morton은 양심고백을 하나 하였다.
사실 direct reclaim path에서의 write가 어느날 갑자기 심해졌다는 것이다.
아마 2.6.16 근처였던 것으로 기억하며 아무도 그 문제에 대해서 fix하려고
시도하지 않았다는 것이다. 또한 writeback을 다른 곳으로 돌리는 것은
2.5.10에 시도되었었지만 그리 효과가 없었다고 말하며 address_space를
pinning할 수 없어 writearound 자체가 구현하기 쉽지 않다고 말하고 있다.
Dave의 patch에 관해서는 flusher는 target zone을 고려하지 않고 있어
잘못된 페이지들만을 계속해서 flush하는 상황이 발생하며 이는 system을
livelockable하게 만들수도 있다고 한다. 여기에 barrios는 한가지 더 우려가
되는 것은 LRU distance와 상관없는 페이지들을 대거 writeout함으로써
이어지는 write-merge등에 손해를 볼 수 있고, working set들이 밀려나가게
되어버리는 일도 발생할 수 있다고 생각한다.
Andrew는 I/O pattern 문제를 해결하기 위해서 이전에 언급했던
"왜 갑자기 direct reclaim path에서 많은 I/O가 발생하기 시작하였나?
우리가 그 문제를 피할수는 없는 것인가?" 부터 생각해야 하며
Stack Overflow문제를 풀기 위해서는 자신없어하며 target page를
다른 쓰레드에게 패스하여 해당 쓰레드와 동기를 맞추면 어떨까 한다.
현재까지 이 문제에 대한 별다른 해결책이 없어 보이는 가운데
James Bottomley는 이번 MM summit과 FS summit이 함께 열리기 때문에
그때까지도 문제가 해결이 되지 않으면 그 자리에서 안건을 올려 한번 얘기해보자고
하고 이에 다른 개발자들은 이 제안에 환영하고 있다. 그 이유는 이미 FS 개발자들에게
random I/O 문제는 consensus를 이룬 문제이며, 정말 문제는 MM guys들이
이 문제를 이해하지 못하고 있다고 생각하고 있기 때문이다. 사실 MM guys들이
이해를 못하고 있는 것이 아니라, 어떻게든 많은 부분을 수정하지 않고 고쳐보려고
하는 것이다. -_-;; 하지만 barrios의 생각으론 FS guys들의 의견에 전적으로
동의한다. 간만에 MM summit이 열리는데 재밌는 안건이 될 것이다.
비록 참석은 못하더라도 재밌는 토론거리가 될 것 같다.
0 개의 덧글:
Post a Comment