Performance degradation seen after using one list for hot/cold pages Jun 25, 2009

얼마전 보고된 내용이다.

http://marc.info/?l=linux-mm&m=124565003222392&w=4

I/O performance가 degradation되었다는 내용이다.
문제의 원인은 Mel의 PCP 패치때문이었다.
PCP는 원래 hot/cold의 분리된 list로 관리되고 있었지만, Mel은 그 2개의 list를 하나로 합치면서
cold page는 뒤에서부터 할당하고, hot page는 앞에서부터 할당하였다.

그래서 발생한 문제가 cold page에 대해서 기존에는 A-B-C-D의 연속된 페이지의 순서로 할당되었던 PFN들이
이제는 D-C-B-A의 order로 할당될 수 있다는 것이다. 이는 연속된 order의 buffer들을 merge하여 처리할 수 있는
I/O device의 성능 저하를 초래하게 된다.

현재 page allocator는 PCP를 채울때 연속된 페이지의 order를 유지하려고 애쓴다. 이 또한 그러한 I/O device들을 염두에 둔 것이다. 하지만 Mel의 PCP 패치가 이 약속을 깨버린 것이다.

Mel은 이 report에 대해서 이미 알고 있었지만 왜 인지 당시에 patch는 만들지 못하였다.
이번 패치는 이 문제를 해결하기 위해서 PCP에 page를 add할때 cold 페이지의 경우에 역순으로 배치하여,
나중에 연속된 page의 순서대로 할당 가능하게 해준다.

이문제에 대해서 barrios가 이 바쁜 시간(대체 요근래 모하고 사는지를 모르겠다. 내가 정말 엔지니어인지에 대하여 심각하게 고민을 하고 있는 중)을 짬내어 언급하는 이유는 이문제가 국내의 기업이 report한 문제이기 때문이며, report를 했던 이는 이미 이 문제의 원인에 대해서 알고 있었기 때문이다.

국내 기업이 이런 critical한 report를 OpenSource 진영에 하는 것은 사실 처음 봤기 때문이다.
국내 기업의 Open Source에 대한 자세가 긍정적으로 변한 것일까?..
하지만 아쉽게도 올린이가 외국인인 것으로 봐서 해외 연구소의 연구원일 것으로 생각된다.
아마도 국내에서는 쉽게 저런 글을 함부로 report하지 못했을 것이다.
아침부터 쓸쓸하구만.

Common OOM killer Problem in Embedded System Jun 23, 2009

금일 report된 Oops이다.

http://lkml.org/lkml/2009/6/22/604

친절하게 Kame-san이 원인을 잘 설명해주고 있다.

이번 문제는 사실 swap device를 가지고 있지 않은 Embedded System에서는 흔한 문제이다.
문제를 살펴보면,
먼저, 메모리 할당 실패는 order 2, 즉 16K의 연속된 메모리 할당에 있어 실패하였다.

Total : 256M
LRU(active + inactive) : 75M
unevictable : 124M
SLAB : 6M
Free + pagetable : 29M

위의 메모리 상태를 보면 시스템의 Memory leack은 아닐것이라고 추측해 볼 수 있다.
또한 위의 정보를 통해 알 수 있는 내용은
1. unevitable이 저렇게 많이 채워져 있는 이유는 tmpfs를 rootfs로 사용했기 때문이라고 추측할 수 있으며
2. file lru가 거의 비워져 있는 것으로 봐서 이미 memory pressure가 상당했다는 것이다.

다음으로 buddy를 살펴보자.

Normal: 1445*4kB 1781*8kB 15*16kB 2*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 20396kB

16k의 연속된 페이지가 15개나 있다. 또한 64k도 하나 있고..
그럼 왜 OOM이 발생한 것일까?

Kame-san이 친절히 얘기해 준 것처럼 zone_watermark_ok의 zone defensive algorithm 때문이다.
(사실 Kame의 계산은 조금 틀렸다. 하지만 zone_watermark_ok가 fail한 건 사실이니.)

많은 embedded system들이 swap device가 없음으로 인해 anon page들을 회수할 수 없게 되고 그로인해 memory fragmentation 문제가 심각해져 발생하는 문제이다. (갑자기 떠오른 생각을 적어 놓는다. no swap system의 lumpy reclaim은 anon page를 고려해야 한다!)

이를 해결하는 방법은 swap을 사용하거나 app 메모리 사용량을 줄이거나..
또는 아직 검증되진 않았지만 compcache(http://lwn.net/Articles/334649/)와 같은 방법을 사용하거나...