http://lists-archives.org/linux-kernel/19778435-cpuset-mm-fix-allocating-page-cache-slab-object-on-the-unallowed-node-when-memory-spread-is-set.html
크리스마스 징검다리 연휴가 들어가기전 report되었던 버그이다.
Miao라는 중국 fujitsu 개발자이다.
문제는 memory_spread_page가 set되어 cupset's mem이 변경되었을 때 slab이 바로 그 사항을 반영하지 못하여 old mem에서 메모리를 할당한다는 것이다.
것도 문제이지만 더 큰 문제는 해당 패치가 kernel's hot path에서 polling하는 루틴을 넣었다는 것이다. 이에 대해 다른 개발자들은 모라고 할 것인지 그 추이를 지켜보고 있었는데 아니나 다를까 Andrew는 다음과 같은 문제를 제기했다.
c) These are two of the kernel's hottest code paths. We really
really really really don't want to be polling for some dopey
userspace admin change on each call to __cache_alloc()!
d) How does slub handle this problem?
C는 barrios와 같은 의견이고 D에 대해 Christoph가 모라고 답변을 할지 기대된다. 그 추이를 지켜보자.
1 개의 덧글:
Chrisotoph가 입을 열었다. SLUB은 SLAB과는 달리 object level에서 memory policy를 다루지 않는다는 것이다. 이는SLQB도 마찬가지이다. 즉 memory policy는 page level로 buddy에게 맡긴다는 것인데..이렇게 하는 것이 NUMA arch에서는 더 효율적이라는 의견이다. 그럴 수 밖에 없는게 NUMA는 cache miss의 cost가 UMA보다 훨씬 크기 때문에 중간에 allocation path가 바뀌게 되면 cache miss가 커지기 때문이다. 그러므로 한 페이지 내의 모든 object을 다 소진한 뒤 다음 page 할당에 대해 memory policy를 반영하여(이는 buddy allocator에서 하게 됨) cache를 최대한 hot하게 유지하고 memory policy도 반영할 수 있게 design했다는 것이다. barrios 또한 위의 패치에 대해 근본적인 의문을 가지고 있다. 과연 memory policy의 변경의 response가 instantly리 반영되어야 하는 건가?? SLUB와 같이 delay되면 큰 문제가 없는 것인가??
Post a Comment