Linux 메모리 모델: 메모리 관리에 대한 심층적인 이해

Linux 시스템에서 다양한 메모리 문제를 겪어본 적이 있나요? 메모리 누수, 메모리 조각화 등 이러한 문제는 Linux 메모리 모델에 대한 깊은 이해를 통해 해결될 수 있습니다.

1. 서문

Linux 커널은 플랫 메모리 모델, 불연속 메모리 모델, 희소 메모리 모델이라는 세 가지 메모리 모델을 지원합니다. 소위 메모리 모델은 실제로 CPU 관점에서 물리적 메모리의 분포와 Linux 커널에서 이러한 물리적 메모리를 관리하는 데 사용되는 방법을 나타냅니다. 또한 이 기사에서는 주로 공유 메모리 시스템에 초점을 맞추고 있습니다. 즉, 모든 CPU가 물리적 주소 공간을 공유한다는 의미입니다.

이 글의 내용은 다음과 같이 구성되어 있습니다. 메모리 모델을 명확하게 분석하기 위해 2장에서 몇 가지 기본 용어를 설명합니다. 세 번째 장에서는 세 가지 메모리 모델의 작동 원리를 설명합니다. 마지막 장에서는 코드 분석을 위해 4.4.6 커널에서 가져온 코드를 분석합니다.

2. 메모리 모델 관련 용어

1. 페이지 프레임이란 무엇인가요?

운영체제의 가장 중요한 기능 중 하나는 컴퓨터 시스템의 다양한 자원을 관리하는 것입니다. 가장 중요한 자원인 메모리만큼 우리는 이를 관리해야 합니다. Linux 운영 체제에서는 페이지 크기에 따라 물리적 메모리가 관리되며, 특정 페이지 크기는 하드웨어와 관련이 있으며 Linux 시스템 구성은 가장 일반적인 설정입니다. 따라서 물리 메모리의 경우 페이지 크기별로 배열된 페이지로 나누어 각 물리 메모리에 있는 페이지 크기의 메모리 영역을 페이지 프레임이라고 합니다. 각 물리적 페이지의 사용을 추적하기 위해 각 물리적 페이지 프레임에 대한 구조체 페이지 데이터 구조를 설정합니다. 커널의 텍스트 세그먼트에 사용됩니까? 아니면 프로세스의 페이지 테이블인가요? 각종 파일 캐시에 사용되는 건지, 아니면 프리 상태인 건지...

각 페이지 프레임에는 일대일 대응 페이지 데이터 구조가 있습니다. 시스템은 페이지 프레임 번호와 페이지 데이터 구조 간 변환을 위해 page_to_pfn 및 pfn_to_page 매크로를 정의합니다. 구체적인 변환 방법은 3장에서 설명합니다. 에서는 Linux 커널의 세 가지 메모리 모델에 대해 자세히 설명합니다.

2.PFN이란 무엇인가요?

컴퓨터 시스템의 경우 전체 물리적 주소 공간은 0부터 시작하여 실제 시스템이 지원할 수 있는 최대 물리적 공간으로 끝나는 주소 공간이어야 합니다. ARM 시스템에서 물리 주소가 32비트라고 가정하면 물리 주소 공간은 4G입니다. ARM64 시스템에서 지원되는 물리 주소 비트 수가 48이면 물리 주소 공간은 256T입니다. 물론 실제로 이렇게 큰 물리적 주소 공간이 모두 메모리에 사용되는 것은 아니며 일부는 I/O 공간에도 속합니다(물론 일부 CPU 아치에는 자체 독립적인 io 주소 공간이 있습니다). 따라서 메모리가 차지하는 물리적 주소 공간은 제한된 간격이어야 하며 전체 물리적 주소 공간을 커버하는 것은 불가능하다. 그러나 이제 메모리가 점점 커지고 32비트 시스템의 경우 4G 물리적 주소 공간은 더 이상 메모리 요구 사항을 충족할 수 없으므로 하이 메모리라는 개념이 있는데 이에 대해서는 나중에 자세히 설명합니다.

PFN은 페이지 프레임 번호의 약어입니다. 소위 페이지 프레임은 물리적 메모리를 페이지 크기 영역으로 나누어 각 페이지에 번호를 매깁니다. 물리적 메모리가 주소 0에서 시작한다고 가정하면 PFN이 0인 페이지 프레임은 주소 0(물리적 주소)에서 시작하는 페이지입니다. 물리적 메모리가 주소 x에서 시작한다고 가정하면 첫 번째 페이지 프레임 번호는 (x>>PAGE_SHIFT)입니다.

3. 누마란 무엇인가요?

다중 프로세서 시스템을 위한 메모리 아키텍처를 설계할 때 두 가지 옵션이 있습니다. 하나는 UMA(균일 메모리 액세스)입니다. 어떤 프로세서가 메모리 주소에 대한 액세스를 시작하는지에 관계없이 시스템의 모든 프로세서는 통일되고 일관된 물리적 메모리 공간을 공유합니다. 는 ~와 마찬가지로. NUMA(Non-uniform memory access)는 UMA와 다릅니다. 특정 메모리 주소에 대한 액세스는 메모리와 프로세서 간의 상대적 위치와 관련됩니다. 예를 들어, 노드에 있는 프로세서의 경우 로컬 메모리에 액세스하는 것이 원격 메모리에 액세스하는 것보다 시간이 더 오래 걸립니다.

3. Linux 커널의 세 가지 메모리 모델

1. FLAT 메모리 모델이란 무엇인가요?

시스템의 모든 프로세서의 관점에서 물리적 메모리에 액세스할 때 물리적 주소 공간이 구멍이 없는 연속 주소 공간이라면 이 컴퓨터 시스템의 메모리 모델은 플랫 메모리입니다. 이 메모리 모델에서는 물리적 메모리 관리가 상대적으로 간단합니다. 각 물리적 페이지 프레임은 이를 추상화하는 페이지 데이터 구조를 갖습니다. 따라서 시스템에는 구조체 페이지 배열(mem_map)이 있으며 각 배열 항목은 다음을 가리킵니다. 실제 물리적 페이지입니다. 플랫 메모리의 경우 PFN(페이지 프레임 번호)과 mem_map 배열 인덱스 간의 관계는 선형입니다(고정 오프셋이 있으며 메모리에 해당하는 물리적 주소가 0이면 PFN이 배열 인덱스임). 따라서 PFN에서 해당 페이지 데이터 구조로 이동하거나 그 반대로 이동하는 것이 매우 쉽습니다. 자세한 내용은 page_to_pfn 및 pfn_to_page 정의를 참조하세요. 또한 플랫 메모리 모델의 경우 노드가 하나만 있습니다(struct pglist_data)(불연속 메모리 모델과 동일한 메커니즘을 사용하기 위해). 아래 그림은 플랫 메모리 상황을 설명합니다.

구조체 페이지가 차지하는 메모리는 직접 매핑된 범위에 있으므로 운영 체제에서 페이지 테이블을 만들 필요가 없다는 점을 강조해야 합니다.

2. 불연속 메모리 모델이란 무엇입니까?

CPU의 주소 공간에 구멍이 있고 물리적 메모리에 액세스할 때 불연속적인 경우 이 컴퓨터 시스템의 메모리 모델은 불연속 메모리입니다. 일반적으로 NUMA 기반 컴퓨터 시스템의 메모리 모델은 불연속 메모리입니다. 그러나 두 개념은 실제로 다릅니다. NUMA는 메모리 모델과는 아무런 관련이 없는 메모리와 프로세서 간의 위치 관계를 강조합니다. 그러나 동일한 노드에 있는 메모리와 프로세서는 더 긴밀한 결합 관계(빠른 액세스)를 가지므로 이를 관리하려면 여러 노드가 필요합니다. 불연속 메모리는 기본적으로 플랫 메모리 메모리 모델의 확장입니다. 전체 물리적 메모리의 주소 공간 대부분은 중간에 일부 구멍이 있는 큰 메모리 조각입니다(있는 경우). 내부적으로 노드의 메모리 모델은 플랫 메모리로 제한됩니다. 아래 그림은 불연속 메모리의 상황을 설명합니다.

따라서 이 메모리 모델에는 여러 노드 데이터(struct pglist_data)가 있으며 매크로 정의 NODE_DATA는 지정된 노드의 struct pglist_data를 가져올 수 있습니다. 그러나 각 노드에서 관리하는 물리적 메모리는 struct pglist_data 데이터 구조의 node_mem_map 멤버에 저장됩니다(이 개념은 플랫 메모리의 mem_map과 유사합니다). 이때 PFN에서 특정 구조체 페이지로 변환하는 것은 조금 더 복잡합니다. 먼저 PFN에서 노드 ID를 가져온 다음 이 ID를 기반으로 해당 pglist_data 데이터 구조를 찾은 다음 해당 페이지 배열을 찾아야 합니다. 후속 방법은 유사한 플랫 메모리입니다.

3. 희소 메모리 모델이란 무엇입니까?

메모리 모델도 진화 과정입니다. 처음에는 연속 메모리 주소 공간(mem_maps[])을 추상화하는 데 플랫 메모리가 사용되었습니다. NUMA 등장 이후에는 전체 불연속 메모리 공간이 여러 노드로 분할되었으며 각 노드는 연속적인 메모리 주소 공간입니다. 즉, 원래 단일 mem_maps[]가 여러 개의 mem_maps[]가 되었습니다. 모든 것이 완벽해 보이지만 메모리 핫플러그의 등장으로 원래의 완벽한 디자인이 불완전해졌습니다. 노드의 mem_maps[]조차 불연속적일 수 있기 때문입니다. 실제로, 희소 메모리가 등장한 이후에는 불연속 메모리 모델이 더 이상 중요하지 않습니다. 이는 결국 희소 메모리가 불연속 메모리를 대체할 수 있는 이유가 됩니다. 4.4 커널에는 여전히 세 가지 메모리 모델이 진행 중입니다. 중에서 선택하세요.

희소 메모리가 결국 불연속 메모리를 대체할 수 있다고 말하는 이유는 무엇인가요? 실제로 희소 메모리 메모리 모델에서는 연속적인 주소 공간을 SECTION(예: 1G)에 따라 섹션으로 나누고 각 섹션을 핫플러그하므로 희소 메모리에서는 메모리 주소 공간을 더 많이 나눌 수 있습니다. 자세한 섹션은 더 많은 개별 불연속 메모리를 지원합니다. 또한 희소 메모리가 등장하기 전에는 NUMA와 불연속 메모리가 항상 혼란스러운 관계에 있었습니다. NUMA는 메모리의 연속성을 규정하지 않았으며 불연속 메모리 시스템은 반드시 NUMA 시스템은 아니었지만 이 두 구성은 모두 다중 메모리입니다. 마디. 희소 메모리를 사용하면 마침내 메모리 연속성 개념을 NUMA와 분리할 수 있습니다. NUMA 시스템은 플랫 메모리 또는 희소 메모리일 수 있고 희소 메모리 시스템은 NUMA 또는 UMA일 수 있습니다.

아래 그림은 희소 메모리가 페이지 프레임을 관리하는 방법을 보여줍니다(SPARSEMEM_EXTREME가 구성됨).

(참고: 위 그림의 mem_section 포인터는 페이지를 가리켜야 하며 페이지에는 여러 구조체 mem_section 데이터 단위가 있습니다)

전체 연속된 물리적 주소 공간은 섹션 단위로 잘려져 있습니다. 각 섹션 내에서 해당 메모리는 연속적입니다(즉, 플랫 메모리의 특성을 따릅니다). 따라서 mem_map의 페이지 배열이 섹션 구조에 연결됩니다. struct mem_section) 노드 구조(struct pglist_data) 대신. 물론 어떤 메모리 모델을 사용하더라도 PFN과 페이지 간의 대응을 처리해야 하지만 희소 메모리에는 섹션이라는 개념이 추가되어 PFNSectionpage로 변환됩니다.

먼저 PFN에서 페이지 구조로 변환하는 방법을 살펴보겠습니다. mem_section 포인터 배열은 커널에서 정적으로 정의됩니다. 섹션에는 여러 페이지가 포함되는 경우가 많기 때문에 섹션 번호를 사용하여 오른쪽으로 이동하여 PFN을 섹션 번호로 변환해야 합니다. 인덱스의 경우 PFN에 해당하는 섹션 데이터 구조는 mem_section 포인터 배열에서 찾을 수 있습니다. 섹션을 찾은 후 해당 section_mem_map을 따라 해당 페이지 데이터 구조를 찾을 수 있습니다. 그런데 처음에는 희소 메모리가 1차원 memory_section 배열(포인터 배열이 아님)을 사용했습니다. 이 구현은 특히 희소(CONFIG_SPARSEMEM_EXTREME) 시스템의 경우 메모리를 매우 낭비합니다. 또한, 핫플러그 지원을 위해 포인터를 저장해 두는 것이 더 편리합니다. 포인터가 NULL이면 해당 섹션이 존재하지 않는다는 의미입니다. 위 그림은 1차원 mem_section 포인터 배열(SPARSEMEM_EXTREME이 구성됨)의 상황을 설명합니다. SPARSEMEM_EXTREME 구성이 아닌 경우에도 특정 작업에 대한 개념은 비슷합니다.

페이지에서 PFN으로 이동하는 것은 약간 번거롭습니다. 실제로 PFN은 두 부분으로 나누어집니다. 한 부분은 섹션 인덱스이고 다른 부분은 섹션 내 페이지의 오프셋입니다. 먼저 페이지에서 섹션 인덱스를 가져온 다음 해당 memory_section을 가져와야 합니다. memory_section을 안다는 것은 페이지가 section_mem_map에 있다는 것을 의미하며, 마지막으로 섹션에 있는 페이지의 오프셋도 알 수 있습니다. . 페이지를 섹션 인덱스로 변환하는 경우 희소 메모리에는 두 가지 솔루션이 있습니다. 먼저 페이지->플래그(SECTION_IN_PAGE_FLAGS가 구성됨)에 저장되는 기존 솔루션을 살펴보겠습니다. 이 방법의 가장 큰 문제는 이 플래그가 너무 많은 정보를 전달하기 때문에 페이지->플래그의 비트 수가 충분하지 않다는 것입니다. 이제 다양한 페이지 플래그, 노드 ID 및 영역 ID가 달성할 수 없는 섹션 ID를 추가합니다. 다양한 아키텍처의 일관성. 범용 알고리즘이 있습니까? CONFIG_SPARSEMEM_VMEMMAP입니다. 구체적인 알고리즘은 아래 그림을 참조하세요.

(위 그림에는 문제가 있습니다. vmemmap은 PHYS_OFFSET이 0일 때 첫 번째 구조체 페이지 배열만 가리킵니다. 일반적으로 오프셋이 있어야 하는데 바꾸기엔 너무 게으른데요, 하하)

클래식 희소 메모리 모델의 경우 섹션의 구조체 페이지 배열이 차지하는 메모리는 초기화 중에 페이지 테이블이 설정되고 페이지 프레임이 할당되므로 가상 주소가 할당됩니다. 그러나 SPARSEMEM_VMEMMAP의 경우 처음부터 가상 주소가 할당된다. 이는 vmemmap부터 시작하는 연속적인 가상 주소 공간이다. 각 페이지에는 해당하는 구조체 페이지가 있으며 물론 물리적 주소는 없다. 따라서 섹션이 발견되면 해당 구조체 페이지의 가상 주소를 즉시 찾을 수 있다. 물론 물리적인 페이지 프레임을 할당한 후 페이지 테이블을 구축하는 것도 필요하다. 오버헤드가 약간 더 커집니다(매핑을 설정하는 프로세스가 하나 더 추가됨).

4. 코드 분석

우리의 코드 분석은 주로 include/asm-generic/memory_model.h를 통해 수행됩니다.

1. 플랫 메모리. 코드는 다음과 같습니다:

“

으아아아

”

코드에서 PFN과 구조체 페이지 배열(mem_map) 인덱스가 선형적으로 관련되어 있음을 알 수 있으며, ARCH_PFN_OFFSET이라는 고정 오프셋이 있습니다. 이 오프셋은 추정된 아키텍처와 관련이 있습니다. ARM64의 경우에는 arch/arm/include/asm/memory.h 파일에 정의되어 있다. 물론 이 정의는 메모리가 차지하는 물리적 주소 공간과 관련이 있다(즉, PHYS_OFFSET의 정의와 관련이 있다).

2. 불연속 메모리 모델. 코드는 다음과 같습니다:

“

\#define __pfn_to_page(pfn) \ ({ unsigned long __pfn = (pfn); \ unsigned long __nid = arch_pfn_to_nid(__pfn); \ NODE_DATA(__nid)->node_mem_map + arch_local_page_offset(__pfn, __nid);\ }) \#define __page_to_pfn(pg) \ ({ const struct page *__pg = (pg); \ struct pglist_data *__pgdat = NODE_DATA(page_to_nid(__pg)); \ (unsigned long)(__pg - __pgdat->node_mem_map) + \ __pgdat->node_start_pfn; \ })

로그인 후 복사

”

Discontiguous Memory Model需要获取node id，只要找到node id，一切都好办了，比对flat memory model进行就OK了。因此对于__pfn_to_page的定义，可以首先通过arch_pfn_to_nid将PFN转换成node id，通过NODE_DATA宏定义可以找到该node对应的pglist_data数据结构，该数据结构的node_start_pfn记录了该node的第一个page frame number，因此，也就可以得到其对应struct page在node_mem_map的偏移。__page_to_pfn类似，大家可以自己分析。

3、Sparse Memory Model。经典算法的代码我们就不看了，一起看看配置了SPARSEMEM_VMEMMAP的代码，如下：

“

\#define __pfn_to_page(pfn) (vmemmap + (pfn)) \#define __page_to_pfn(page) (unsigned long)((page) - vmemmap)

로그인 후 복사

”

简单而清晰，PFN就是vmemmap这个struct page数组的index啊。对于ARM64而言，vmemmap定义如下：

“

\#define vmemmap ((struct page *)VMEMMAP_START - \ SECTION_ALIGN_DOWN(memstart_addr >> PAGE_SHIFT))

로그인 후 복사

”

毫无疑问，我们需要在虚拟地址空间中分配一段地址来安放struct page数组（该数组包含了所有物理内存跨度空间page），也就是VMEMMAP_START的定义。

总之，Linux内存模型是一个非常重要的概念，可以帮助你更好地理解Linux系统中的内存管理。如果你想了解更多关于这个概念的信息，可以查看本文提供的参考资料。

위 내용은 Linux 메모리 모델: 메모리 관리에 대한 심층적인 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!