TIL 23.6.12 // 컴퓨터 메모리 페이징에서 왜 4KiB를 사용하는지에 관하여.

https://dictionary.cambridge.org/us/pronunciation/english/mebibyte

How to pronounce MEBIBYTE in English

 

https://www.youtube.com/watch?v=Dqt7fsvw1-8 

 

https://ko.wikipedia.org/wiki/%EB%A9%94%EB%AA%A8%EB%A6%AC_%EA%B4%80%EB%A6%AC_%EC%9E%A5%EC%B9%98

메모리 관리 장치 - 위키백과, 우리 모두의 백과사전

 

https://ko.wikipedia.org/wiki/%EB%B3%80%ED%99%98_%EC%83%89%EC%9D%B8_%EB%B2%84%ED%8D%BC

변환 색인 버퍼 - 위키백과, 우리 모두의 백과사전

 

https://dlforbi.tistory.com/17

[OS] 페이징 시스템(Paging System)

 

메모리 주소를 1<<32승 만큼 표현 할 수 있고, 하나의 메모리 주소가 가리키는 값은, 

일반적으로 컴퓨터 시스템에서 메모리는 바이트 단위로 구성되고, 주소가 표현하는 각 메모리 위치는 1바이트 크기의 데이터를 가리키니까, 

1<<32승 바이트 만큼의 사이즈이고, 그게 4GB이다. 

 

 

 

 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

운영체제 세가지 이야기 책에서

197p  가상 페이지 번호 virtual page numbr (VPN) 20비트

199p 18.2장 페이지 테이블은 어디에 저장되는가 => 페이지 테이블 항목(page table entry, PTE) 12비트

200~201 페이지 테이블 항목 (page table entry, PTE) 의 요소들에 대하여.

 

 

 

 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

https://stackoverflow.com/questions/11543748/why-is-the-page-size-of-linux-x86-4-kb-how-is-that-calculated

Why is the page size of Linux (x86) 4 KB, how is that calculated?

 

Introduction

The first Intel processor that supported the paging virtual memory technique was the Intel 80386. The processor supported a single page size, 4 KB. Since it was released in 1985, we have to go back to that period of time to understand why Intel chose that particular page size.

 

페이징 가상 메모리 기술을 지원한 최초의 인텔 프로세서는 인텔 80386이었습니다. 이 프로세서는 단일 페이지 크기인 4KB를 지원했습니다. 이 프로세서는 1985년에 출시되었으므로 인텔이 왜 특정 페이지 크기를 선택했는지 이해하려면 그 시기로 거슬러 올라가야 합니다.

 

Atlas was the first computer to support paging with a page size of 3 KB and it had a profound influence on the design of virtual memory and motivated related research. The system was designed between 1958-1962. It's interesting to note that the page size supported by the 80386 is somewhat close to the page size supported by the Atlas, even though the 80386 was designed about 20 years later and computers (and the workloads they ran) have evolved radically during that period of time! In fact, many computers from that period used page sizes that range between 0.5-5 KB. Researchers at that time actually spent a substantial amount of effort studying virtual memory systems (paging and segmentation).

 

Atlas는 페이지 크기가 3KB인 페이징을 지원하는 최초의 컴퓨터로, 가상 메모리 설계에 지대한 영향을 미쳤으며 관련 연구에 동기를 부여했습니다. 이 시스템은 1958~1962년 사이에 설계되었습니다. 80386이 약 20년 후에 설계되었고 그 기간 동안 컴퓨터(및 컴퓨터가 실행하는 워크로드)가 급격하게 발전했음에도 불구하고 80386이 지원하는 페이지 크기가 Atlas가 지원하는 페이지 크기와 어느 정도 비슷하다는 점은 흥미롭습니다! 실제로 당시의 많은 컴퓨터는 0.5~5KB 범위의 페이지 크기를 사용했습니다. 당시 연구원들은 실제로 가상 메모리 시스템(페이징 및 세분화)을 연구하는 데 상당한 노력을 기울였습니다.

 

One of the big questions was: What is the optimal page size? A large number of works were published in the 60s and 70s that attempt to study and understand the impact of the page size on the performance of applications and recommend or provide guidelines on how to choose a page size. There are certainly a number of papers that were never published. As far as I know, this includes the document from Intel that says "... Therefore, the page size should be 4 KB." But the factors that influence or interact with the page size and the process of choosing a page size (or multiple page sizes for that matter) are well known, which is what I'll discuss in this answer at a basic level. I'll also explain in particular why a page size of 4 KB is reasonable.

 

큰 질문 중 하나는 최적의 페이지 크기는 무엇인가? 60년대와 70년대에 페이지 크기가 애플리케이션의 성능에 미치는 영향을 연구하고 이해하여 페이지 크기를 선택하는 방법을 추천하거나 가이드라인을 제공하려는 많은 논문이 발표되었습니다. 출판되지 않은 논문도 분명히 많이 있습니다. 제가 아는 한 여기에는 "... 따라서 페이지 크기는 4KB가 되어야 합니다."라는 인텔의 문서도 포함됩니다. 그러나 페이지 크기에 영향을 미치거나 상호 작용하는 요소와 페이지 크기(또는 여러 페이지 크기)를 선택하는 프로세스는 잘 알려져 있으므로 이 답변에서는 기본적인 수준에서 논의하겠습니다. 또한 4KB의 페이지 크기가 합리적인 이유에 대해서도 구체적으로 설명하겠습니다.

The Page Size Problem

페이지 크기 문제

 

In the paging method, physical memory is organized as a sequence of contiguous regions of memory, called page frames, that are of the same size (which is the defining characteristic of paging(주석1). Each page frame can be mapped to equally-sized chunk of a virtual address space, called a virtual page.

 

페이징 방식에서 물리적 메모리는 페이지 프레임이라고 하는 동일한 크기의 연속적인 메모리 영역으로 구성됩니다(이는 페이징의 정의적 특성입니다(주석1). 각 페이지 프레임은 가상 페이지라고 하는 가상 주소 공간의 동일한 크기 청크에 매핑할 수 있습니다.

 

Suppose that a page consists of N bytes(주석2) (which implies that a page frame is also N bytes in size by definition) and consider a virtual address space that consists of P pages (i.e., the page numbers are {0, 1, 2, ..., P - 1} and the total number of virtual addresses is N * P). Suppose also that the physical address space consists of F page frames (i.e., the page frame numbers are {0, 1, 2, ..., F - 1} and the total number of physical addresses is N * F).

 

페이지가 N 바이트(주석2)로 구성되어 있다고 가정하고(정의상 페이지 프레임의 크기도 N 바이트임을 의미함), P 페이지로 구성된 가상 주소 공간을 고려합니다(즉, 페이지 번호는 {0, 1, 2, ..., P - 1}이고 가상 주소의 총 개수는 N * P임). 또한 물리적 주소 공간이 F 페이지 프레임으로 구성되어 있다고 가정합니다(즉, 페이지 프레임 번호는 {0, 1, 2, ..., F - 1}이고 물리적 주소의 총 개수는 N * F입니다).

 

Given a virtual address VA, a mechanism (a mapping device) is required to determine the physical address, PA, it is mapped to or a page fault should be raised in case it was not mapped. The mapping device uses a data structure (the page table) stored somewhere to perform the mapping. There should be an entry in that table for each allocated virtual page that describes how the page is mapped and potentially some additional attributes (such as protection attributes). The design of the page table entry, as you'll see, interacts with the page size. I'll discuss the design of the page table entry in the Intel 80386 later.

 

가상 주소 VA가 주어지면 이 주소가 매핑되는 실제 주소인 PA를 결정하기 위한 메커니즘(매핑 장치)이 필요하거나 매핑되지 않은 경우 페이지 오류가 발생해야 합니다. 매핑 장치는 어딘가에 저장된 데이터 구조(페이지 테이블)를 사용하여 매핑을 수행합니다. 할당된 각 가상 페이지에 대해 해당 테이블에 페이지가 매핑되는 방법과 잠재적으로 몇 가지 추가 속성(예: 보호 속성)을 설명하는 항목이 있어야 합니다. 페이지 테이블 항목의 디자인은 보시다시피 페이지 크기와 상호 작용합니다. 인텔 80386의 페이지 테이블 항목 디자인에 대해서는 나중에 설명하겠습니다.

 

The size of a virtual address is log2(N * P) and the size of a physical address is log2(N * F). Some bits of VA would represent the offset within the page while the other bits would represent the page number, which identifies the page using the mapping device.

 

가상 주소의 크기는 log2(N * P)이고 물리적 주소의 크기는 log2(N * F)입니다. VA의 일부 비트는 페이지 내의 오프셋을 나타내고 다른 비트는 매핑 장치를 사용하여 페이지를 식별하는 페이지 번호를 나타냅니다.

 

How many options do we have for the page size? Well, it can be as a little as one byte up to N * P or N * F, whichever is smaller. That's a lot of options.

 

페이지 크기에는 몇 가지 옵션이 있나요? 최소 1바이트부터 최대 N * P 또는 N * F 중 더 작은 크기까지 가능합니다. 정말 많은 옵션이 있습니다.

 

It is Convenient for The Page Size to be a Power of 2

페이지 크기는 2의 거듭제곱인 것이 편리합니다.

 

A virtual address, VA, is equivalent to a pair of page number and offset, (PN, OFF). The translation process should be as efficient as possible. It's convenient for programmers(주석3) to have the bytes within a page to be contiguous in the address space. In this way, the addresses of the items within a multi-byte data structure can be calculated with simple arithmetic on a single address, which would constitute the base address of the data structure. This can be achieved by using the least significant log2(N) bits (rounded up) of a virtual address to represent the offset and the rest of the bits to represent the page number.

 

가상 주소인 VA는 한 쌍의 페이지 번호와 오프셋(PN, OFF)에 해당합니다. 변환 프로세스는 가능한 한 효율적이어야 합니다. 프로그래머(주석3)는 한 페이지 내의 바이트가 주소 공간에서 연속되도록 하는 것이 편리합니다. 이렇게 하면 다중 바이트 데이터 구조 내의 항목의 주소를 데이터 구조의 기본 주소가 되는 단일 주소에서 간단한 산술로 계산할 수 있습니다. 가상 주소의 최하위 log2(N) 비트(반올림)는 오프셋을 나타내고 나머지 비트는 페이지 번호를 나타내는 데 사용함으로써 이를 달성할 수 있습니다.

 

If N is not power of 2, there will be some bits that are shared between the offset and page number, depending on the values of these bits. By making N a power of 2, such complication does not exist. So it would neat to use page sizes that are a power of 2. All real processors that support paging use page sizes that are power of two (although the unit of addressability may not be 8 bits), which makes sense. But to be honest, it's not clear whether this really matters. Using today's technology, whether N is a power of 2 may not have any measurable impact on performance or any other metric of interest. In fact, in the future as larger and larger page sizes are needed, it may happen that some page size that is not a power of 2 is better. But so far, this has not happened. The point I'm trying to make here is that the design option of making the page size not a power 2 should not be automatically dismissed. I believe this is a good opportunity of research in future virtual memory systems.

 

N이 2의 거듭제곱이 아닌 경우, 이러한 비트의 값에 따라 오프셋과 페이지 번호 간에 공유되는 비트가 일부 존재합니다. N을 2의 거듭제곱으로 만들면 이러한 복잡성이 존재하지 않습니다. 따라서 2의 거듭제곱인 페이지 크기를 사용하는 것이 깔끔할 것입니다. 페이징을 지원하는 모든 실제 프로세서는 2의 거듭제곱인 페이지 크기(주소 지정 단위가 8비트가 아닐 수도 있음)를 사용하므로 이는 합리적입니다. 하지만 솔직히 이것이 정말 중요한지는 확실하지 않습니다. 오늘날의 기술로는 N이 2의 거듭제곱인지 여부가 성능이나 기타 관심 있는 지표에 측정 가능한 영향을 미치지 않을 수 있습니다. 실제로 앞으로 점점 더 큰 페이지 크기가 필요해지면 2의 거듭제곱이 아닌 일부 페이지 크기가 더 좋을 수도 있습니다. 하지만 지금까지는 그런 일이 일어나지 않았습니다. 제가 여기서 말하고자 하는 요점은 페이지 크기를 2의 거듭제곱이 아닌 크기로 만드는 디자인 옵션이 자동으로 무시되어서는 안 된다는 것입니다. 저는 이것이 미래의 가상 메모리 시스템에 대한 좋은 연구 기회라고 생각합니다.

 

Anyway, keeping in mind that the choice of 4 KB pages was made in the 80s, such extremely small variations in page sizes were shown (both theoretically and experimentally) to be of little importance. So the convenience of power-of-2 page sizes triumphed. This reduces the number of page sizes to consider exponentially. But we still have a good range of options.

 

어쨌든 4KB 페이지의 선택이 80 년대에 이루어 졌다는 점을 염두에두고 페이지 크기의 극히 작은 변화는 (이론적으로나 실험적으로) 거의 중요하지 않은 것으로 나타났습니다. 따라서 2의 거듭제곱 페이지 크기의 편리함이 승리했습니다. 이렇게 하면 고려해야 할 페이지 크기가 기하급수적으로 줄어듭니다. 하지만 여전히 다양한 옵션이 있습니다.

 

Favoring Smaller Page Sizes

작은 페이지 크기 선호

 

Since the mapping device works at the level of pages, the unit of allocation from the perspective of the operating system is a virtual page(주석4). Even if an application needs to only allocate 1 byte, it still has to tell the OS to allocate a whole virtual page for that 1 byte. This issue is called internal fragmentation. Each application (or maybe even each component of an application) has its own virtual address space from which it allocates memory in page-size chunks. It's expected from each application to not use a single page for a single object that it allocates, but rather allocate as many objects as possible from the same page before it allocates more pages. However, because page attributes work at the level of pages, the same application may use multiple user-mode memory managers (such as when using multiple C/C++ runtimes), and it's difficult for application to share parts of the pages they are not using with other applications, internal fragmentation can occur in many pages in the system. Using smaller page sizes can help reduce the amount of wasted physical (for the whole system) and virtual (per process) memory.

 

매핑 장치는 페이지 수준에서 작동하기 때문에 운영 체제 관점에서 할당 단위는 가상 페이지입니다(주석4). 애플리케이션이 1바이트만 할당해야 하는 경우에도 해당 1바이트에 대해 전체 가상 페이지를 할당하도록 OS에 지시해야 합니다. 이 문제를 내부 조각화라고 합니다. 각 애플리케이션(또는 애플리케이션의 각 구성 요소)에는 페이지 크기의 청크로 메모리를 할당하는 자체 가상 주소 공간이 있습니다. 각 애플리케이션은 할당하는 단일 객체에 대해 단일 페이지를 사용하지 않고 동일한 페이지에서 가능한 한 많은 객체를 할당하여 더 많은 페이지를 할당하는 것이 바람직합니다. 그러나 페이지 속성은 페이지 수준에서 작동하기 때문에 동일한 애플리케이션이 여러 사용자 모드 메모리 관리자를 사용할 수 있고(예: 여러 C/C++ 런타임을 사용하는 경우) 애플리케이션이 사용하지 않는 페이지의 일부를 다른 애플리케이션과 공유하기 어렵기 때문에 시스템의 많은 페이지에서 내부 조각화가 발생할 수 있습니다. 더 작은 페이지 크기를 사용하면 낭비되는 물리적(전체 시스템) 및 가상(프로세스별) 메모리의 양을 줄일 수 있습니다.

 

In addition, typically applications go through a number of phases throughout their lifetime, where they exhibit different memory requirements in different phases. If the page size is, say, 16 KB, but many applications may require only less 10 KB for many of their phases, then there would be a lot of wasted physical memory, which may lead to out-of-memory situations that could have been avoided if smaller page sizes, such as 8 or 4 KB, were supported.

 

또한 일반적으로 애플리케이션은 수명 기간 동안 여러 단계를 거치는데, 각 단계마다 메모리 요구 사항이 달라집니다. 예를 들어 페이지 크기가 16KB이지만 많은 애플리케이션이 많은 단계에서 10KB 미만의 메모리만 필요로 하는 경우, 낭비되는 물리적 메모리가 많아져 8KB 또는 4KB와 같이 더 작은 페이지 크기를 지원했다면 피할 수 있었던 메모리 부족 상황이 발생할 수 있습니다.

 

Smaller page sizes are preferable for handling copy-on-write soft page faults because the smaller the page is, it would take less time to create a copy of it. For extremely small page sizes, this may not make any measurable difference, depending on the memory bus bandwidth.

 

페이지 크기가 작을수록 복사본을 만드는 데 걸리는 시간이 줄어들기 때문에 페이지 크기가 작을수록 쓰기 시 소프트 페이지 오류를 처리하는 데 유리합니다. 페이지 크기가 매우 작은 경우 메모리 버스 대역폭에 따라 측정 가능한 차이가 없을 수도 있습니다.

 

Typical amounts of physical memory available in computers in the 70s were in the range of 10s or 100s of KBs. It wouldn't make sense to have page sizes of hundreds of KBs or larger. In fact, the working sets of applications at that time were typically only few or tens of KBs. So even page sizes as small as 16 KB are unlikely to be practical because only a couple of pages may consume all of the available physical memory. The page size should be coherent with the amount of physical memory. This argument can be applied to today's systems of course (it wouldn't make sense to have 128-GB pages for example).

 

70년대 컴퓨터에서 사용 가능한 물리적 메모리의 일반적인 용량은 10~100KB 범위였습니다. 수백 KB 이상의 페이지 크기를 갖는다는 것은 말이 안 되는 일이었습니다. 실제로 당시 애플리케이션의 작업 세트는 일반적으로 몇 개 또는 수십 KB에 불과했습니다. 따라서 16KB 정도의 작은 페이지 크기라도 몇 페이지만 있으면 사용 가능한 물리적 메모리를 모두 소모할 수 있기 때문에 실용적이지 않았습니다. 페이지 크기는 물리적 메모리의 양과 일관성을 유지해야 합니다. 이 주장은 물론 오늘날의 시스템에도 적용될 수 있습니다(예를 들어 128GB 페이지를 사용하는 것은 이치에 맞지 않습니다).

 

So considering working set sizes and physical memory availability of the 70s and early 80s, the page size should be a power of 2 in the range 2^0-2^14. Cool, now we have only 15 options to choose from.

 

따라서 70년대와 80년대 초반의 작업 세트 크기와 물리적 메모리 가용성을 고려할 때 페이지 크기는 2^0-2^14 범위에서 2의 거듭제곱이 되어야 합니다. 이제 선택할 수 있는 옵션이 15개밖에 없습니다.

 

Favoring Larger Page Sizes

더 큰 페이지 크기 선호

 

We can also argue that larger page sizes are better. For the same working set, smaller page sizes imply a larger number of pages per application , which would require page table entries to enable translation. This fundamentally requires larger page tables irrespective of the structure of the page tables (although the exact overhead depends on the design of the page table entry itself, which I'll discuss later). Imagine having for example 4-byte pages and typical working sets of tens of KBs. Then most of the physical memory would actually be allocated to hold the page tables, not the data. Paging out page tables to seconding storage leads to double page faults for individual memory references, which would be absolutely terrible for performance. Such design is obviously ridiculous.

 

또한 페이지 크기가 클수록 더 좋다고 주장할 수도 있습니다. 동일한 작업 세트의 경우 페이지 크기가 작을수록 애플리케이션당 페이지 수가 많아지므로 번역을 활성화하려면 페이지 테이블 항목이 필요합니다. 이를 위해서는 기본적으로 페이지 테이블의 구조에 관계없이 더 큰 페이지 테이블이 필요합니다(정확한 오버헤드는 페이지 테이블 항목 자체의 디자인에 따라 달라지지만 나중에 설명하겠습니다). 예를 들어 4바이트 페이지와 수십 KB의 일반적인 작업 세트가 있다고 상상해 보세요. 이 경우 대부분의 물리적 메모리는 실제로 데이터가 아닌 페이지 테이블을 저장하는 데 할당됩니다. 페이지 테이블을 세컨드 스토리지로 페이징하면 개별 메모리 참조에 대한 이중 페이지 오류가 발생하고, 이는 성능에 절대적으로 좋지 않은 영향을 미칩니다. 이러한 설계는 명백히 말도 안 되는 것입니다.

 

Essentially, the page size shouldn't be (much) smaller than the smallest possible working set size that can possibly ever be. This immediately rules out pages of sizes 2^0-2^6, leaving for us 8 options. The papers of the 70s and early 80s that study page sizes mostly study only these 8 options.

 

기본적으로 페이지 크기는 가능한 가장 작은 작업 세트 크기보다 (훨씬) 작아서는 안 됩니다. 이렇게 하면 2^0-2^6 사이즈의 페이지는 즉시 배제되고 8가지 옵션이 남습니다. 페이지 크기를 연구한 70년대와 80년대 초반의 논문은 대부분 이 8가지 옵션만 연구했습니다.

 

There is another reason that makes larger page sizes advantageous. One of the benefits of virtual memory is to be able to transparently use secondary storage in addition to main memory to hold volatile data. However, secondary storage devices are mechanical and perform best with bulk transfers. This is more of a guideline really and we should not rule out any page sizes yet. There are devices with different designs and characteristics and eventually, the performance advantage of bulk transfers will saturate at some point. But it's certainly something to take into account when measuring the impact of page sizes on performance. If the type of applications being considered exhibit little spatial locality, then smaller page sizes would still be preferable because copying extra bytes to or from the disk is not exactly for free.

 

더 큰 페이지 크기가 유리한 또 다른 이유가 있습니다. 가상 메모리의 장점 중 하나는 휘발성 데이터를 보관하기 위해 주 메모리 외에 보조 스토리지를 투명하게 사용할 수 있다는 점입니다. 하지만 보조 저장 장치는 기계식이며 대량 전송 시 가장 성능이 좋습니다. 이는 가이드라인에 가깝기 때문에 아직 어떤 페이지 크기도 배제해서는 안 됩니다. 다양한 디자인과 특성을 가진 장치들이 존재하며, 결국 대량 전송의 성능 이점은 언젠가는 포화 상태가 될 것입니다. 하지만 페이지 크기가 성능에 미치는 영향을 측정할 때 반드시 고려해야 할 사항입니다. 고려 중인 애플리케이션 유형이 공간적 로컬리티가 거의 없는 경우에는 디스크에 추가 바이트를 복사하거나 디스크에서 복사하는 것이 무료가 아니므로 페이지 크기가 더 작은 것이 더 바람직할 수 있습니다.

 

Spatial locality of reference encourages the use of certain page sizes. For very small page sizes, it's highly likely that all bytes in the page will be used in the a small period of time. As the size of a page gets larger, the number of bytes that are less likely to be used increases. However, for very large pages, all of the working set may fit within a small number of pages irrespective of locality. Therefore, to minimize the number of page faults, the page size should be either too small or too larger, but not in between. But ultimately, this varies from one application to another. Emerging programming paradigms, such as object-oriented programming and functional programming, and techniques such as multithreading may actually reduce spatial locality due to the extensive use of linked structures and due to the way different application interact with each other. Larger page sizes are preferable to reduce the number of page faults. However, smaller page sizes might be better for memory shared between multiple applications to reduce internal fragmentation of the shared pages. It has also been shown experimentally that the number of page frames that can be held in main memory is correlated with the number of page faults, favoring smaller page sizes.

 

참조의 공간적 위치는 특정 페이지 크기를 사용하도록 권장합니다. 페이지 크기가 매우 작은 경우 페이지의 모든 바이트가 짧은 시간 내에 사용될 가능성이 높습니다. 페이지 크기가 커질수록 사용 가능성이 낮은 바이트 수가 증가합니다. 그러나 매우 큰 페이지의 경우 지역에 관계없이 모든 작업 세트가 적은 수의 페이지에 들어갈 수 있습니다. 따라서 페이지 오류 수를 최소화하려면 페이지 크기가 너무 작거나 너무 크지 않아야 하지만 그 중간이 되어서는 안 됩니다. 그러나 궁극적으로 이는 애플리케이션마다 다릅니다. 객체 지향 프로그래밍 및 함수형 프로그래밍과 같은 새로운 프로그래밍 패러다임과 멀티스레딩과 같은 기술은 연결된 구조의 광범위한 사용과 서로 다른 애플리케이션이 서로 상호 작용하는 방식으로 인해 실제로 공간적 로컬리티를 감소시킬 수 있습니다. 페이지 결함 수를 줄이려면 페이지 크기가 클수록 좋습니다. 그러나 여러 애플리케이션 간에 메모리를 공유하는 경우에는 공유 페이지의 내부 조각화를 줄이기 위해 페이지 크기가 더 작을 수 있습니다. 또한 메인 메모리에 저장할 수 있는 페이지 프레임 수는 페이지 오류 수와 상관관계가 있어 페이지 크기가 작을수록 유리하다는 것이 실험적으로 입증되었습니다.

 

The need for TLBs was well recognized at that time. Intel called them page caches in their patents (not sure whether Intel was first to use that term). Fast TLBs are very important because address translation is on the critical path of executing instructions. To make them as fast as possible, they should be made tiny, but then they can only cache a small number of page table entries. This motivates the use of larger page sizes.

 

당시에는 TLB의 필요성을 잘 알고 있었습니다. 인텔은 특허에서 이를 페이지 캐시라고 불렀습니다(인텔이 이 용어를 처음 사용했는지는 확실하지 않음). 주소 변환은 명령어를 실행하는 중요한 경로에 있기 때문에 빠른 TLB는 매우 중요합니다. 가능한 한 빠르게 만들려면 작게 만들어야 하지만, 그러면 적은 수의 페이지 테이블 항목만 캐시할 수 있습니다. 이는 더 큰 페이지 크기를 사용하도록 동기를 부여합니다.

 

In the search for the optimal page size, it turns out that there isn't one. It was known at that time that there is a need for supporting multiple page sizes. In fact, the Multics system designed in 1965 supported 64- or 1,024-word pages (a word is 36 bits in size). Page sizes in the range 27-214 were shown to be optimal both empirically and theoretically in different scenarios. Intel must have observed that 4-KB pages result in the best average performance for the applications that their customers used in the 80s. For today's computers and applications, such tiny differences in page sizes don't make much difference as it used to be in the 70s and 80s.

 

최적의 페이지 크기를 검색한 결과 페이지 크기가 없는 것으로 나타났습니다. 당시에는 여러 페이지 크기를 지원할 필요가 있다는 것이 알려졌습니다. 실제로 1965년에 설계된 Multics 시스템은 64단어 또는 1,024단어 페이지를 지원했습니다(한 단어는 36비트 크기). 2^7-2^14 범위의 페이지 크기는 다양한 시나리오에서 경험적, 이론적으로 모두 최적인 것으로 나타났습니다. 인텔은 80년대에 고객이 사용하던 애플리케이션의 평균 성능이 4KB 페이지에서 가장 좋다는 것을 관찰했을 것입니다. 오늘날의 컴퓨터와 애플리케이션의 경우 70~80년대와 마찬가지로 페이지 크기의 작은 차이는 큰 차이를 만들지 않습니다.

 

The Design of the Page Table Entry of the Intel 80386

인텔 80386의 페이지 테이블 항목 디자인

 

The design of the page directory entry and page table entry is discussed in detail in an Intel patent. This is important because the size of the page table entry and the overall structure of the page table were taken into account in many studies about the page size because they all interact with each other. I prefer not to discuss this in more detail to keep the answer short.

 

페이지 디렉토리 항목과 페이지 테이블 항목의 설계는 인텔 특허에 자세히 설명되어 있습니다. 페이지 테이블 항목의 크기와 페이지 테이블의 전체 구조는 모두 서로 상호 작용하기 때문에 페이지 크기에 대한 많은 연구에서 고려되었기 때문에 이 부분이 중요합니다. 답변을 짧게 하기 위해 이에 대해 더 자세히 설명하지 않겠습니다.

 

The Page Size of the Near Future

가까운 미래의 페이지 크기

 

Intel has been granted a patent a couple of months ago that apparently proposes a system with a default page size of 64 KB, but at the same time supporting 4 KB pages (and other IA-32e page sizes) for backward compatibility. I quote from the patent:

 

인텔은 몇 달 전에 기본 페이지 크기가 64KB인 시스템을 제안하는 특허를 받았지만, 동시에 이전 버전과의 호환성을 위해 4KB 페이지(및 기타 IA-32e 페이지 크기)를 지원하는 것으로 보입니다. 특허를 인용합니다:

 

As a result of support of the mapping of the 64 KB page into 4 KB subpages, VA64 directly supports all currently defined operations on 4 KB pages, including independent protection bits per 4 KB page and arbitrary 4 KB-aligned address mappings. VA64 also supports OS kernel page management on 4 KB boundaries, even when the OS kernel allocates memory in 64 KB units. As a result of support of large pages, VA64 supports all divisions of the virtual address range into pages that an existing paging system such as Intel Corporation's IA-32e paging system supports. Therefore, VA64 supports applications and hardware devices that work with a 4 KB-page Windows® OS kernel, while also taking full advantage of 64 KB pages when 64 KB pages can be used.

64KB 페이지를 4KB 하위 페이지로 매핑하는 것을 지원하므로 VA64는 4KB 페이지당 독립적인 보호 비트 및 임의의 4KB 정렬 주소 매핑을 포함하여 현재 4KB 페이지에 정의된 모든 작업을 직접 지원합니다. 또한 VA64는 OS 커널이 64KB 단위로 메모리를 할당하는 경우에도 4KB 경계에서 OS 커널 페이지 관리를 지원합니다. 대용량 페이지 지원의 결과로 VA64는 인텔사의 IA-32e 페이징 시스템과 같은 기존 페이징 시스템이 지원하는 가상 주소 범위의 모든 분할을 페이지로 지원합니다. 따라서 VA64는 4KB 페이지 Windows® OS 커널에서 작동하는 애플리케이션 및 하드웨어 장치를 지원하는 동시에 64KB 페이지를 사용할 수 있는 경우 64KB 페이지를 최대한 활용할 수 있습니다.

The capabilities of VA64 can be adopted gradually by the OS kernel, rather than requiring them all to be supported in the first generation VA64-capable OS kernel. For example, a VA64-capable OS kernel could start by mapping all pages to current sizes (e.g., 4 KB/2 GB/1 TB in Intel Corporation's IA-32e paging system), but changing to a new page table format. After the change in page table format, the OS kernel could be modified to map virtual memory in 64 KB units and change to store 64 KB pages in its free list. Then the OS kernel could start using 64 KB pages whenever alignment and protections permit, and add support for other VA64 capabilities.

VA64의 기능은 1세대 VA64 지원 OS 커널에서 모두 지원해야 하는 것이 아니라 OS 커널에서 점진적으로 채택할 수 있습니다. 예를 들어, VA64 지원 OS 커널은 모든 페이지를 현재 크기(예: Intel Corporation의 IA-32e 페이징 시스템에서 4KB/2GB/1TB)로 매핑하는 것으로 시작하지만 새로운 페이지 테이블 형식으로 변경할 수 있습니다. 페이지 테이블 형식이 변경된 후 OS 커널을 수정하여 가상 메모리를 64KB 단위로 매핑하고 여유 목록에 64KB 페이지를 저장하도록 변경할 수 있습니다. 그런 다음 OS 커널은 정렬 및 보호가 허용될 때마다 64KB 페이지를 사용하기 시작하고 다른 VA64 기능에 대한 지원을 추가할 수 있습니다.

I don't know anything else about the VA64 paging system other than what's written in the patent. There is nothing on it anywhere on the Internet. I guess we'll find out more soon.

 

VA64 페이징 시스템에 대해 특허에 적힌 내용 외에는 아무것도 모릅니다. 인터넷 어디에도 관련 정보가 없습니다. 곧 더 많은 것을 알게 되겠죠.

 

Selected References

Denning, P.J. (1970). Virtual memory. ACM Computing Surveys Volume 2 Issue 3, 153-189.

Gelenbe, E., Tiberio, P., & Boekhorst, J. C. A. (1973). Page size in demand-paging systems. Acta Informatica, 3(1), 1-23.

Alanko, T. O., & Verkamo, A. I. (1983). Segmentation, paging and optimal page sizes in virtual memory. Performance Evaluation, 3(1), 13-33.

Corbató, F. J., & Vyssotsky, V. A. (1965). Introduction and overview of the Multics system. In Proceedings of the November 30--December 1, 1965, fall joint computer conference, part I (pp. 185-196).

---

Footnotes

(1) Actually the size of a single virtual page can be multiple of the size of a page frame, but let's not go there.

 

(1) 실제로 단일 가상 페이지의 크기는 페이지 프레임 크기의 여러 배가 될 수 있지만 여기서는 다루지 않겠습니다.

 

(2) We can generalize the formulation and use the term "word" to refer to the smallest addressable unit of memory rather than byte, but that is not important here.

 

(2) 공식을 일반화하여 바이트가 아닌 주소 지정이 가능한 가장 작은 메모리 단위를 가리키는 '워드'라는 용어를 사용할 수 있지만, 여기서는 중요하지 않습니다.

 

(3) Maybe not programmers, depending on the programming language, but compilers, linkers, assemblers, and tools that work with binary code.

 

(3) 프로그래밍 언어에 따라 프로그래머가 아닌 컴파일러, 링커, 어셈블러 및 바이너리 코드로 작업하는 도구일 수도 있습니다.

 

(4) It's certainly possible to design a system that supports using paging and nonpaging at the same time, thereby potentially supporting multiple units of allocation, but let's not go there.

 

(4) 페이징과 비페이징을 동시에 사용하도록 지원하여 잠재적으로 여러 할당 단위를 지원하는 시스템을 설계할 수는 있지만 여기서는 다루지 않겠습니다.

 

 

+++++++++++++++++++++++++++++++++++++++++++++++++++++

위와 같이 제시된 내용에 대한 gpt 요약본

 

 

가상 메모리 시스템에서 특정 페이지 크기를 선택하는 것은 여러 가지 요인에 영향을 받습니다. 제공된 텍스트에서 논의된 주요 사항을 요약해 보겠습니다:

 

2의 거듭제곱 페이지 크기의 편리함: 2의 거듭제곱 페이지 크기를 사용하면 간단하고 효율적인 주소 계산이 가능합니다. 가장 낮은 비트는 페이지 내의 오프셋을 나타내고, 나머지 비트는 페이지 번호를 나타냅니다. 이 설계 선택은 프로그래머에게 편리하며, 페이지를 지원하는 모든 실제 프로세서에서 채택되었습니다.

 

더 작은 페이지 크기 선호: 더 작은 페이지 크기는 내부 단편화를 줄이는 데 도움이 됩니다. 더 작은 양이 필요한 경우에도 메모리는 페이지 크기의 청크로 할당됩니다. 더 작은 페이지 크기로 하면 하나의 페이지 내에 더 많은 객체를 할당할 수 있어 메모리 낭비를 줄일 수 있습니다. 또한, 더 작은 페이지 크기는 복사 필요한 경우에도 복사하는 데 걸리는 시간이 적어지므로 복사-읽기-쓰기 소프트 페이지 폴트 처리에 유리합니다.

 

더 큰 페이지 크기 선호: 더 큰 페이지 크기는 주소 변환을 위해 필요한 페이지 테이블 엔트리 수를 줄일 수 있으며, 이는 페이지 테이블의 크기를 줄입니다. 이는 더 큰 작업 집합을 가진 응용 프로그램에 유리합니다. 더 큰 페이지 크기는 보조 저장 장치 사용 시 대량 전송의 성능 이점을 얻을 수 있습니다.

 

물리 메모리와의 일관성: 페이지 크기는 사용 가능한 물리 메모리와 일관성을 가져야 합니다. 물리 메모리가 제한적인 경우 극단적으로 큰 페이지 크기는 비효율적인 메모리 할당을 초래할 수 있습니다. 70년대와 80년대 초에는 물리 메모리의 가용성을 고려하여 페이지 크기를 2^0에서 2^14 범위의 2의 거듭제곱으로 선택해야 합니다.

 

공간적 국부성과 작업 집합 크기: 응용 프로그램의 작업 집합 크기(자주 액세스되는 메모리)는 페이지 크기 선택에 영향을 미칩니다. 공간적 국부성이 높은 응용 프로그램의 경우 더 작은 페이지 크기가 더 적합합니다. 더 작은 페이지 크기는 페이지 내의 모든 바이트가 짧은 시간 내에 사용될 가능성이 높기 때문입니다. 공간적 국부성이 낮은 경우 페이지 폴트 수를 줄이기 위해 더 큰 페이지 크기가 적합할 수 있습니다. 그러나 여러 응용 프로그램 간에 공유되는 메모리의 경우 내부 단편화를 줄이기 위해 더 작은 페이지 크기가 선호될 수 있습니다.

 

TLB 고려 사항: 주소 변환의 효율성을 위해 TLB(번역 후보 버퍼)는 중요합니다. 더 큰 페이지 크기는 TLB 액세스가 더 빨라질 수 있습니다. TLB는 일부 페이지 테이블 엔트리를 캐시하기 때문에 더 빠른 TLB 액세스는 주소 변환의 성능을 향상시킵니다.

 

특정한 4 KB 페이지 크기가 Intel 80386 프로세서에서 선택된 것은 그 시기에 고객이 사용한 응용 프로그램의 성능 특성과 작업 요구 사항에 영향을 받았을 가능성이 큽니다. 시간이 지남에 따라 기술의 발전과 응용 프로그램 요구 사항의 변화로 인해 페이지 크기의 작은 차이의 중요성은 줄어들었습니다.

 

미래에 대해서는 Intel은 VA64라는 시스템을 위한 특허를 획득했는데, 이는 64 KB의 기본 페이지 크기를 제안하면서 하위 호환성을 위해 4 KB 페이지도 지원합니다. 이는 더 큰 페이지 크기가 앞으로도 관련이 있을 수 있다는 것을 시사합니다.

이 요약은 제공된 텍스트를 기반으로 작성되었으며, 가상 메모리 시스템의 페이지 크기 선택에 대한 모든 가능한 요소와 고려 사항을 포함하지 않을 수 있음을 참고해 주세요.

 

 

 

 

++++++++++++++++++++++++++++++++

<메모장 저장 내용>

 

70년대 컴퓨터에서 사용 가능한 물리적 메모리의 일반적인 용량은 10~100KB 범위였습니다. 수백 KB 이상의 페이지 크기를 갖는다는 것은 말이 안 되는 일이었습니다. 

따라서 70년대와 80년대 초반의 작업 세트 크기와 물리적 메모리 가용성을 고려할 때 페이지 크기는 2^0-2^14 범위에서 2의 거듭제곱이 되어야 합니다. 이제 선택할 수 있는 옵션이 15개밖에 없습니다.

<너무 작아지면 실제 데이터가 아닌 페이지 테이블을 저장하는데 많이 할당된다.>
 
TLB=>가능한 한 빠르게 만들려면 작게 만들어야 하지만, 그러면 적은 수의 페이지 테이블 항목만 캐시할 수 있습니다. 이는 더 큰 페이지 크기를 사용하도록 동기를 부여합니다.

인텔은 80년대에 고객이 사용하던 애플리케이션의 평균 성능이 4KB 페이지에서 가장 좋다는 것을 관찰했을 것입니다

오늘날의 컴퓨터와 애플리케이션의 경우 70~80년대와 마찬가지로 페이지 크기의 작은 차이는 큰 차이를 만들지 않습니다.


**오늘날에는 그렇게 큰 차이를 만들어내는건 아닌듯** 



인텔은 몇 달 전에 기본 페이지 크기가 64KB인 시스템을 제안하는 특허를 받았지만, <<동시에 이전 버전과의 호환성을 위해 4KB 페이지(및 기타 IA-32e 페이지 크기)를 지원하는 것으로 보입니다.>>
특허를 인용합니다:

결론
프로세서가 지원해야 하고, 그걸 운영체제가 지원해야하고, 
60~70년대 많은 연구가 이루어졌고, 80년대 인텔이 그 당시 기준으로 4kb 페이지가 가장 좋다는 것을 관찰했다. 
근데 현대의 컴퓨터는 그렇게 큰 영향을 받는 수준은 아니다.