리눅스 커널의 물리 메모리 관리는 페이지 단위로 이루어진다. 그렇다면 예를 들어 19byte를 요청한다고 해서 시스템의 페이지 단위인 4K byte가 할당될까? 그렇지는 않다. 예를 들어 kmalloc을 사용하여 19 byte를 요청하게 되면 32byte가 할당된다. 그렇다면 kmalloc은 어떻게 32byte를 할당하게 할까? 이것이 이번 장에서 얘기할 슬랩 할당자 덕분이다.
커널이 관리하는 페이지 단위는 커널에서 사용하기에 다소 큰단위이다. 4K가 응용 프로그램을 개발하는 분들은쉽게 생각할지 모르겠지만 커널의 입장에서 많은 함수들이 4K씩 사용한다는 것은 시스템의 치명적인 성능저하를 유발할 수도 있으며 메모리 단편화를 너무 많이 일으켜 금방 시스템의 성능저하로 이어지게 될 것이다. 그러므로 커널 입장에서는 몇 byte요청을 4K로 되돌려 준다는 것은 용납할 수 없는 일이된다.
예를 들어19byte를 요청한 입장에서 4K가 할당되었다는 것은 나머지 4077 byte는 사용자가 free하지 않는 한 시스템의 입장에서는 사용하지 못하는 영역이 되버리고 말기 때문이다.
이를 우리는 멋있는 말로 내부 단편화라고 한다. 내부 단편화문제를 해결하기 위하여 슬랩 할당자가 나오게 되었다.
슬랩은 내부 단편화 문제를 해결할 뿐만이 아니라 커널 내에서 흔히 일어나는 dynamic memory 할당의 overhead를 줄이기 위하여 캐싱하는 역할을 하여 성능 개선에도 큰 도움을 주고 있다. 슬랩 할당자의 기본 구조는 다음과 같다. 하나의 캐시를 나타내는 kmem_cache_s 구조체는 kmem_list3 구조체를 통하여 slab들을 관리하며슬랩 내에는 사용자에게 할당할 object들이 저장되어 있는 풀 구조이다.
캐시는 관리가 필요한 오브젝트 종류별로(예를 들면task_struct, file, buffer_head, inode 등) 작성되고 그 오브젝트의 슬랩을 관리한다. 슬랩은 하나 이상의 연속된 물리 페이지로 구성되어 있으며 일반적으로 하나의 페이지로 구성된다. 캐시는 이러한 슬랩들의 복수개로 구성된다.
캐시에는 다음과 같은 3가지의 슬랩 리스트가 있다.
● slab_full : 슬랩내의 오브젝트가 전부 사용 중인 것
● slab_partial : 슬랩내의 오브젝트가 사용중인 것과 미사용중인 것이 혼재되어 있는 것
● slabs_empy : 슬랩내의 오브젝트가 전부 미사용인 슬랩 리스트
위와 같은 구조를 통하여 자주 사용되는 오브젝트들을 미리 할당하여 놓고 사용자 요구가 있을 때 마다 바로 반환하는 것이다. 이것은 물리 메모리를 확보하기 위하여 검색 및 회수, 반환과 같은 긴 여행을 떠날 필요가 없으므로 시스템의 성능을 향상시킨다. 또한 다 사용된 오브젝트들을 반납받아 커널의 메모리 할당자에게 반환하지 않고 보관했다가 재사용하기 때
문에 시스템의 성능을 향상시킬 수 있게 된다.
그렇다면 kmalloc이 어떻게 슬랩 할당자를 사용할까? 그것은 커널이 시스템을 초기화 될 때 kmem_cache_init 함수를 통하여 자주 사용되는 커널의 오브젝트들의 크기를 고려하여 일반적으로 사용할 목적으로 추가적인 캐시들을 생성하기 때문이다. 그 크기는 32/64/128/256/512/1024/4096/8192/16384/32768/65536/131072 byte이다
이는 곧 kmalloc이 할당 할 수 있는 메모리 크기는 128K라는 것을 의미하기도 한다. 커널은 위의 크기의 object로 이루어진 캐시를 미리 할당하여 메모리에 유지하고 있으며 사용자의 요구가 들어왔을 경우 위의 크기 중 가장가깝게 큰 수로 올림하여 할당하게 되므로 페이지 단위로 관리하는 것 보다 내부 단편화를 줄이게 되며 시스템의성능을 향상시키게 된다.
[출처] Slab allocator, Buddy allocator|작성자 다야
'Embedded Lab > linux, x86' 카테고리의 다른 글
[Top-Half와 Bottom-Half] (0) | 2012.01.26 |
---|---|
[인라인(inline) 함수] (0) | 2012.01.11 |
[커널의 종류] (0) | 2012.01.11 |
[프로세스의 상태 정리] (0) | 2012.01.04 |
[커널컴파일] (0) | 2012.01.03 |