come back zero_page Jul 14, 2009

http://lwn.net/Articles/340370/

ZERO_PAGE. Linux kernel의 VM에 관심있는 사람들은 한번쯤 들어봤을 법한
설비이다. Linux kernel은 2.6.24시절까지는 zero page를 사용하여 vma에
최초 발생한 read fault는 zero page에 매핑하였다.

이는 다음과 같은 장점을 가져온다.

1. memory save
2. reduced cache pressure
3. eliminating the need to clear the new page

하지만 24때 Nick에 의해 MuliProcessor system에서 cache line bouncing문제가
심각하다고 밝혀져 제거되었다.(물론 revert되기까지는 많은 discussion이 있었다.
avoiding zero page reference counting, per-cpu zero page등)
cache line bouncing이 발생하는 이유는 많은 CPU들이 하나의 zero page를 공유하게
되면서, zero page의 reference counting 때문에 발생하게 되었다.

그 당시에 Nick의 이런 노력에 사실 Linus는 심기가 불편했지만 일단 Nick의 이 패치가
어떤 문제들을 발생시킬지 보기로 하고는 우선 merge했었다. Linus가 zero page의 제거를
싫어했던 이유는 zero page는 리눅스와 함께 태동했기 때문이다. Linux가 세상에 알려지기
시작할 무렵부터 zero page는 거기에 있었으며, 2.6.24까지도 큰(?) 문제 없이 잘 사용되고
있어왔던 것이다. 그러므로 이미 몇몇 application들은 Linux kernel의 이런 특성(zero page)
을 이미 활용하고 있어왔다. 그러므로 kernel에서 zero page를 제거하게 된다면, 그런 특성을
활용하던 application들의 regression은 피할 수 없게 될 것이다.

정확히 18개월이 지나고, 문제가 터지기 시작했다. 마지막으로 카운터를 날린 것은 Kame였다
Kame는 다음과 같이 주장했다. "Kernel이 바뀌어서 regression이 생겼다고, app 개발자들한테
너희들이 다시 app를 개발해야해!" 라고 말할 수는 없는 것 아니냐고.

Linus의 전폭적인 지지와 함께 zero page의 대한 구현이 다시 시작되었다.(물론 reference counting을
피하기 위해 아소 깨끗하지 못한 구현이 되어가고 있을 무렵..). 다시 한번 Nick은 zero page의 도래를
마땅해하지 못하고 있음을 여러모로 피력하였다. 하지만 Linus는 이미 마음을 굳힌 것 같다. 이에 대해
Nick과 Linus가 다소 격양된 어조의 토론이 있었지만...
언제나 그렇듯이, Linus의 승이다.

결국 우리는 머지 않아 zero page를 다시 보게 될 것이며, 그 구현은 그렇게 평이한 수준이 되지는
않을 것이다.

꼬랑지)
barrios의 기억으로 zero page의 제거가 문제가 된 부분 중의 하나는, core파일을 만들어 낼때이다.
core dump는 기본적으로 프로세스의 모든 vma에 page들을 읽어 file로 덤프를 뜬다.
이때 zero page의 제거는 실제 page를 할당받게 됨으로써, vma의 크기에 따라 순식간에 시스템의
memory를 모두 소비할 수 있게 된다. 그러므로 embedded system에서는 oops로 swap을 가지고 있는
일반 시스템 또한 순식간에 swap out이 발생하게 되어 working set들을 버릴 수도 있게 되며,
그 순간 시스템의 응답성을 떨어뜨리게 된다.

core dump에서 이 문제를 어떻게 해결했는지 barrios는 follow up하지 못하였으며, 이 부분에 대한
언급이 없는 것으로 봐서는 해결이 되었을 것으로 기대한다. (그렇지 않다면 역시 나의 몫!)