tag:blogger.com,1999:blog-1518098013643077976.post1278137689049016858..comments2018-11-13T14:24:44.371+09:00Comments on barrios kernel story: [PATCH] cpuset,mm: fix allocating page cache/slab object on the unallowed node when memory spread is setbarrioshttp://www.blogger.com/profile/17430525060458411817noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-1518098013643077976.post-31217713224874849232009-01-01T21:23:00.000+09:002009-01-01T21:23:00.000+09:00Chrisotoph가 입을 열었다. SLUB은 SLAB과는 달리 object level에서...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되면 큰 문제가 없는 것인가??barrioshttps://www.blogger.com/profile/17430525060458411817noreply@blogger.com