음..제 질문은 128k등 큰 사이즈를 요청할 때 버디로 직접 줄때와 슬랩으로 구성해서 줄 때 차이점이 뭔가하는 거였습니다.

그리고 큰 사이즈를 요청할 수록 슬랩에서도 단편화는 커질텐데(kmalloc(100k, gfp_kernel)을 하면 128k 오브젝트 리턴. 28k 낭비), 굳이 큰 오브젝트를 관리하는 슬랩을 버디에서 페이지를 받아 구성할 이유가 있을까??입니다. 애초에 버디에서 주면 될 것 같은데 말이죠..;;;;;일단 속도는 슬랩에서 주는 것이 더 빠를텐데, 이런 속도 관점 말고 또 다른 이유가 있는지 궁금합니다.

그렇군요. 화끈하게 이해가 되었습니다. ㅋ

감사합니다. ^^;

설명이 명확하지 않았나 봅니다. ㅎ 

1번의 경우는 페이지프레임이 4KB라고 가정하면, 말씀 하신것처럼 4KB 페이지에 작은 커널 오브젝트들을 캐시할때 단편화 관점에서 의미가 있습니다. 하지만 오브젝트가 4KB, 8KB 처럼 4KB의 배수 (정확히는 4*2^{order-1}KB)인 경우는 단편화 문제가 발생할까요? 제가 말씀드린 포인트는 이부분입니다. 따라서 4KB, 8KB *kmalloc 캐시*를 슬랩에 유지할 필요가 있느냐? 하는 것이었습니다. 슬랩의 kmalloc 캐시는 kmalloc() 함수에서 메모리를 할당 받으려고 시도할 때 먼저 찾는 캐시입니다. 4KB, 8KB는 단편화 문제도 발생하지 않을것이기 때문에 궂이 슬랩캐시로 구성하지 않아도 된다는 것이죠.  그래서 속도외에는 이유를 찾을 수가 없다는 것이고 슬랩할당자 개발자분도 속도를 말씀을 하셨습니다. (나중엔 이것이 슬랩할당자 초기의 문제였을 수 있다는 생각이 들더군요. 왜냐하면 슬랩할당자를 사용하지 않았던 버전에서는 팀동료의 모듈의 속도 문제가 없었다는 의미이므로...)

2번의 경우는 말씀하신것도 하나의 이유가 될것 같습니다. 좀 더 정확하게는 해당 오브젝트가 액티브하게 사용된다는 가정이 있어야 합니다. 슬랩의 크기는 축소될 수 있기 때문입니다.

제가 언급한 포인트를 이해하는데 도움이 되셨길 바랍니다.

P.S. 답변에 수정을 하려다 수정하는 것 대신 추가 설명부분을 덧붙힙니다. 

kmalloc() 함수로 4KB 메모리를 할당할때만 4KB kmalloc 캐시가 사용되는 것은 아닙니다. kmalloc() 함수를 통해 3KB를 할당할때 4KB kmalloc 캐시가 사용됩니다. 

이해가 잘 안되네요. ㅋ

1. 포인트로 잡은 것은 /proc/slabinfo를 보면 8KB, 4KB 슬랩 캐시가 보이는데, 이 캐시들은 별로 캐시로 만들 이유가 없어보인다는 것이었습니다. (왜 128KB 캐시에 대한 답이 있었는지 ㅠ.ㅠ)

=> 4KB 보다 작은 커널 오브젝트들의 단편화 방지와 속도 향상을 위해 필요한 것으로 알고 있습니다.

2. "4KB가 넘어가는 2^{order} KB 오브젝트들을 슬랩캐시로 별도로 구성할 필요가 있느냐?"

=> 최소한의 커널 오브젝트의 개수를 보장하기 위함이 아닐까요?

어디까지나 추측이지만 120KB 짜리 A라는 커널 오브젝트 10개를 슬랩 캐시로 가지고 있는 경우는 시스템의 

메모리가 아무리 부족해져도 A를 10개까지 보장 할 수 있습니다. 하지만 슬랩 캐시로 유지 하지 않고 

버디에서 할당 받는다면 10개를 보장 할 수 없게 될듯 싶습니다.