[PATCH] shmem: writepage directly to swap Mar 23, 2009

http://www.gossamer-threads.com/lists/linux/kernel/1050286?page=last

Hugh의 금일 패치이다. 한 줄의 패치이지만 이 패치를 위해서는 그의 수년간의 경험이 녹아 있다.

내용은 다음과 같다.
shmem_writepage 함수는 약간 특별한 함수이다.
왜냐하면 일반적인 다른 file system과는 달리 shmem_writepage가 page를 바로 flush하지 않기 때문이다.

shmem_writepage는 regular writeback이나 sync로부터 호출되지 않는다. 이미 backing device info에서 것을 막는다. 반면, writepage가 호출되는 것은 memory pressure에 의해 page를 swap out 할 때이다.

하지만 이때 다른 파일 시스템처럼 바로 페이지를 block layer로 내려 보내는 것이 아니라,
swap cache를 이용해 한번더 reclaim될 수 있는 기회를 준다. 그렇게 하는 이유는 일반적으로 tmpfs(shared memory를 구현하기 위해 사용된)와 같은 ramfs는(여기서는 그냥 넘어가지만 ramfs와 tmpfs는 엄연히 다른 fs이다. 비록 tmpfs가 ramfs를 모태로 하지만. 언젠가 issue가 있으면 설명할 날이 오겠지)의 목적은 일반 파일 시스템과 다르기 때문이다.

메모리 파일 시스템을 사용하는 사용자의 의도는 특별한 이유가 없으면 파일들이 RAM에 상주하길 바란다는 것이다. 그러므로 shmem_writepage는 바로 회수하는 것이 아닌 한번 더 기회를 주는 것이다.

하지만 문제는 여기서 부터 시작한다. 그리고 이 문제는 SLUB과 얽혀 있기도 하다.

Hugh가 지적한 것이 바로 이것이다. 수년동안 지켜봤는데, shmem page들에게 한번 더 기회를 줘서 얻는 이득이 없다는 것이다. 오히려 해가 되면 해가 됐지.

게다가 2.6.28에서 split lru가 merge되며, tmpfs와 shmem을 SwapBacked 페이지로 다시 분류하였고 이는 file page보다 swap out되기가 더 어렵기 때문에 그 의도는 충분히 반영되었다는 것이다. 일리가 있는 말이다.

그럼 문제가 어떻게 발생했는지 살펴보자.
테스트는 tmpfs workload에서 실험한다.

문제는 shmem_inode_cache에서 부터 시작한다. SLUB을 primary SLAB으로 사용하면서 shmem_inode_cache를 위해서는 슬랩당 4개의 페이지를 사용한다. 그러므로 tmpfs의 workload를 실행하여 많은 inode를 할당하다 보면 4개의 연속된 페이지를 계속 필요로 하게 될 것이다. memory pressure가 점차 심해지자 page scanning이 되며 tmpfs 페이지들이 바로 swap out되는 것이 아니라 swap cache로 이동을 하게 될 것이다. 이때 할당된 swap entry들은 연속된 swap area로 할당될 것이다. (이는 swap file system의 특징이다. 되도록 이면 연속된 swap offset을 할당하여 disk seek을 줄이려는 의도이다.)
부하가 점점 더 심해진다. 결국 4개의 연속된 페이지를 찾기 위해 lumpy가 동작하게 된다.
lumpy의 회수 페이지의 패턴을 분석해보니 첫번째 페이지만 LRU의 bottom에 존재하게 되고, 나머지는 굉장히 random하게 LRU의 중간 중간에서 회수된다는 것이다.
그러므로 swap file system이 아무리 연속된 swap offset을 할당한다 하더라도 결국, 페이지는 scatter되어 writeout되는 꼴이 되어버리고 만 것이다.

이는 flash를 사용하는 장치를 swap device로 사용할 때 큰 문제가 된다. 왜냐하면 flash의 특징은 write를 위해서는 보다 큰 영역을 먼저 erase해야 하기 때문이다. 그러므로 flash의 특성상 random write의 merge는 굉장히 큰 effect를 갖게 된다. 허나 위의 문제로 인해 I/O의 merge 비율이 크게 떨어지면 엎친데 덮친격으로 random write 속도 또한 굉장히 떨어진다는 것이다.

Hugh는 대략 5%의 성능향상이 있다고 말하고 있다.
패치를 보라. 단 한줄 수정했다. (Dummy function 제외하고)

이 한줄을 위해 그가 분석한 자료와 kernel에 대한 지식은 상당하다.
커널 개발자란 적어도 이 정도의 core knowledge를 가지고 있어야 커널 개발자라고
말할수 있지 않을까?