[patch] vmscan: initialize sc.order in indirect shrink_list() users Feb 17, 2009

http://lkml.org/lkml/2009/2/10/231

Hannes의 패치이다.
얼마전 Hannes는 offline mail을 통해서 barrios에게 유익한 정보를 알려주었다.
이는 다음 기회에 소개하기로 하고, 지금은 이 패치의 내용에 대해 살펴보자.

Hannes가 패치한 내용은 memory 회수 루틴 중 2곳에서 현재 메모리 requestor의 order가 반영되지 않았다는 것이다. 첫번째 장손는, 명시적으로 0을 지정할 필요가 없다는 것을 얼마전 Andrew가 친절히 설명해 주었었다.
이번 issue는 두번째인 zone_reclaim 함수에서의 order값 지정의 생략이다.

zone_reclaim 함수의 목적은 page를 할당하기 전, early reclaim을 하는 것이다. early reclaim의 대상은
slab 페이지들과 unmapped file backed page들이다. 즉, read와 같은 system call을 통해서 읽혀진 페이지나, mapped file backed page들 중에, 현재는 unmapped되어 있는 페이지들이다.

이 함수에서 order를 requestor의 order로 지정하지 않은 것이 문제의 시작이다.
하지만 이 쓰레드의 Hannes와 Mel의 대화 속에는 약간의 오해가 있다.

먼저, Hannes가 order를 의도적으로 0으로 지정하지 않았다고 생각하는 이유는 다음과 같다.

Page allocator는 page를 할당하려고 할 때 몇 단계를 거치며 할당자에 pressure를 가한다.
그 pressure는 다음의 flag들로 지정된다.

#define ALLOC_NO_WATERMARKS 0x01 /* don't check watermarks at all */
#define ALLOC_WMARK_MIN 0x02 /* use pages_min watermark */
#define ALLOC_WMARK_LOW 0x04 /* use pages_low watermark */
#define ALLOC_WMARK_HIGH 0x08 /* use pages_high watermark */
#define ALLOC_HARDER 0x10 /* try to alloc harder */

NO_WATERMARK 쪽으로 갈 수록 memory pressure가 심한 것이다.
Page allocator의 첫번째 try는 ALLOC_WMARK_LOW를 사용하게 된다. Hannes가 생각한 것은
WMARK_LOW에서 order를 지정하게 되면, 현재 memory pressure가 별로 없는 상태에서 결국 lumpy reclaim을
하게 되어, 불필요하게 working set page들이 evict되어 버린다는 것이다. 그래서 의도적으로 order를 지정하지 않았다고 생각한다.

이에 대해, Mel은 분명히 잘못된 것이라고 지적하고 있다. 즉 Hannes의 패치가 맞다는 것이다.
그것으로 인해 어떤 차이가 생길지는 알기 어렵지만, zone_reclaim의 semantics상 order를 지정하는 것이 make sense하다는 것이다. 또한 Mel은 Hannes가 걱정한 working set page의 evict에 대해서 high order reclaim에 대한 어쩔수 없는 cost라고 말하고 있다.

마지막 쓰레드의 Hannes와 Mel의 대화를 다시 보면, Mel은 Hannes의 말을 여전히 오해하고 있다. Hannes가 의도한 것은 low watermark에서 굳이 lumpy reclaim까지는 하지 않아도 upcoming allocation은 성공할 것이기 때문에 그렇게 했을 거라는 말이고, Mel은 그 말을 오해하고, 이렇게 언급하며 쓰레드를 끝낸다.

I think I get you now. You are saying that reclaiming order-0 pages increases
the free count so we might get over the watermarks and the allocation would
succeed. Thing is, watermarks calculated in zone_watermark_ok() take order
as a parameter and has this in it.

for (o = 0; o < order; o++) {
/* At the next order, this order's pages become * unavailable */
free_pages -= z->free_area[o].nr_free << o;
So, to reach the low watermarks for a high-order allocation, we still
need lumpy reclaim.

즉, Mel은 "order-0 page를 reclaim하는 것이 전체 free page의 수를 증가시킬 것이며 이는 watermark 이상이 될수 있기 때문에 allocation이 성공할 것이다" 라고 Hannes가 말하고 있다고 생각한다. 하지만 앞서 언급한 바와 같이 Hannes의 의도는 그렇지는 않다. Anyway, Mel로부터 배울 것이 있다. order-0 page를 아무리 reclaim하더라도 결국 zone_watermark_ok는 위와 같이 계산하기 때문에 requestor의 order를 만족시킬 수는 없게 된다는 것이다. 결국 allocation이 성공할 수 없다는 것이다.