메모리 관리자는 시스템의 하위 집합입니다. 운영 운영 체제와 다양한 응용 프로그램간에 메모리를 공유합니다. 메모리라는 용어는 주로 주 메모리 (RAM)를 나타내지 만 관리에는 보조 메모리와 캐시 메모리의 기여가 필요합니다.
메모리 관리자 특히 프로세스에 메모리를 효율적으로 할당하는 역할을합니다.이는 사용 가능한 메모리의 여유 위치를 열거하고, 새 프로세스에 필요한 메모리를 할당하고, 종료되는 프로세스에서 메모리를 회수 할 수 있어야 함을 의미합니다. Linux 커널 내의 프로세스 디스패처는 SLAB 디스패처입니다.
투수판 메모리 요청을 최적화하는 블록 및 캐시 시스템에 의존. 이러한 유형의 메모리 관리는 할당 및 재배치 작업으로 인한 조각화를 줄입니다.
블록 할당에는 특정 개체에 적합한 고정 크기 조각으로 잘린 미리 할당 된 여러 메모리 블록이있는 특정 개체 유형 / 크기에 대한 캐시 구현이 포함됩니다.
SLAB는 조각을 관리하여 커널이 객체에 메모리를 할당하도록 요청하면 기존 블록의 예비 부품으로 해당 요청을 충족 할 수 있습니다. SLAB는 이후에 유사한 개체를 할당 할 때 다시 사용할 수 있도록 할당 된 메모리를 유지하므로 개체 초기화와 관련된 오버 헤드 비용이 줄어 듭니다.
SLAB를 대체하려고합니다.
로만 구 쉬친, Facebook의 Linux 커널 엔지니어링 팀의 일원 인 그는 현재 메모리 관리자 / 컨트롤러에서 "심각한 결함"으로 간주되는 것을 발견했습니다. 그리고 r최근에 새로운 메모리 컨트롤러를 제안 블록 이는 여러 "cgroup"간의 메모리 사용률을 획기적으로 향상시킵니다. (또는 제어 그룹) 메모리에서.
따라서 cgroups는 시스템 리소스 (프로세서, 메모리, 디스크 사용량 등)의 사용을 제한, 계산 및 격리 할 수있는 Linux 커널의 기능과 "페이지의 슬래브»"라는 용어를 참조하는 것이 중요합니다. SLAB에 의해 메모리 할당 프로세스에 동화 될 수 있습니다.
Gushchin에 따르면 :
“기존 설계로 인해 SLAB 사용량이 낮아지는 실제 이유는 간단합니다. 슬랩 페이지는 단일 메모리 풀에서만 독점적으로 사용됩니다.
cgroup에 의해 특정 크기의 할당이 몇 개만 있거나 cgroup이 제거 된 후 활성 객체가 일부 남아 있거나 cgroup에 사실상 커널을 할당하지 않지만 매번 할당하는 단일 스레드 응용 프로그램이 포함 된 경우 새로운 CPU : 이러한 모든 경우에 발생하는 SLAB 사용량은 매우 낮습니다.
kmem 계산이 비활성화 된 경우 커널은 다른 할당을 위해 타일 페이지의 여유 공간을 사용할 수 있습니다.
Gushchin은 kmem 드라이버가 각 메모리 풀에 대해 활성화되어야하는 선택적 기능으로 도입되었을 때 이것이 문제가되지 않았다고 주장합니다.
이제 그러나, kmem 드라이버는 cgroup v1 및 v2에 대해 기본적으로 활성화됩니다. 그리고 최신 시스템은 많은 수의 c 그룹을 생성하는 경향이 있으므로 SLAB를 사용하는 것은 덜 효과적입니다.
그에 따르면 다양한 메모리 그룹간에 슬랩 페이지를 공유하여 페이지가 아닌 개체별로 회계를 수행하는 재 작업 된 시스템을 사용하여 리눅스 커널에는 최적화 된 메모리 컨트롤러가 있습니다. 훨씬 더 효율적인 수준의 사용을 제공합니다.
Gushchin이 제안한 패치에는 두 개의 반독립 요소가 포함되어 있습니다. 하나는 향후 회계 목적으로 사용할 수있는 하위 페이지로드 API와 mem_cgroup_ptr API입니다.
새 컨트롤러로 수행 한 테스트 구 슈친의 기억 Linux에서 35 ~ 42 % 더 많은 메모리를 확보 할 수 있음을 보여주었습니다. 프런트 엔드 웹, 데이터베이스 캐시 및 DNS 서버 및 기타 많은 워크로드에서.
Gushchin의 제안은 현재 "의견 요청"기치 아래에 있습니다. 승인되면 2020 Linux 커널 버전에 통합 될 수 있습니다.
출처 : https://lkml.org/