mainline은 점차 커널 스택 크기를 줄여가고 있는 추세이다. 반면 실무를 하는 회사에서는??
아마도 스택 크기를 늘려달라고 아우성일 것이다.
문제는 자신들의 드라이버에 있음에도 불구하고 커널의 스택 크기를 늘려 해결하려는 것이다.
개발하다보면 가끔(?) 그런 일들에 부딪히곤 한다.
하지만 사실, 그 어디에서도 커널 스택 크기를 늘리면 왜 안되는지에 대한 이유는 나와 있지 않다. 그냥 다들 그러지 말라고말 할 뿐이지..
생각해보면 이것도 커널 메모리하고 밀접한 관련이 있음을 알 수 있다.
일반적으로 user process들이 사용하는 메모리는 4K page이다.
리눅스 커널에서 가장 많이 쓰이는 페이지도 바로 이 4K page이다.
그래서 리눅스 커널은 나름 4K page들의 캐싱에 신경을 써놨고 할당 전략들은 4K page 할당에 많은 신경을 써 놓았다. 그런데 문제는 커널 스택이다.
커널 스택은 x86을 제외하곤(4K) 내가 아는 architecture는 다 8K이다. 8K 할당은 메모리가 충분하면 문제 없지만 최대한 메모리를 모두 써버리는(?) 리눅스의 페이지 캐시 전략에서는 언젠가 메모리는 회수되기 시작할 것이다.
문제는 이 때 발생한다. order가 큰 메모리 요청일 수록 회수 알고리즘은 잘 동작하지 못한다.
그나마 최근 lumpy reclaim으로 인해 좀 나아지긴 했지만, 4K 만 못한 것이 사실이다.
그래서 커널 스택을 4K로 줄이면 줄였지 8K 이상으로 확장하려는 생각은 별로 하지 않는 것이 좋다. OOM killer를 만나보고 싶지 않다면~~
kerner stack size expansion Mar 3, 2008
작성자: barrios 위치 6:46 PM
레이블: linux kernel
Subscribe to:
Post Comments (Atom)
0 개의 덧글:
Post a Comment