왜 세분화가 아닌가?

나는 운영 체제와 x86 아키텍처를 연구하고 있으며, 분할 및 페이징에 대해 읽는 동안 현대 OS가 메모리 관리를 처리하는 방법이 자연스럽게 궁금했습니다. 내가 찾은 것으로부터 리눅스와 대부분의 다른 운영 체제는 본질적으로 페이징에 유리하게 세그먼트 화를 피했다. 내가 찾은 몇 가지 이유는 단순성과 이식성이었습니다.

세그먼트 화 (x86 또는 기타)를위한 실제적인 용도는 무엇이며이를 사용하는 강력한 운영 체제를 보거나 페이징 기반 시스템을 계속 선호 할 것입니다.

이제 이것이로드 된 질문이라는 것을 알고 있지만 새로 개발 된 운영 체제에서 분할이 어떻게 처리되는지 궁금합니다. 아무도 더 '분할 된'접근법을 고려하지 않도록 페이징을 선호하는 것이 이치에 맞습니까? 그렇다면 왜 그렇습니까?

그리고 'shun'세그먼트 화를 말할 때 Linux는 Linux가 필요한만큼만 사용한다는 것을 암시합니다. 사용자 및 커널 코드 / 데이터 세그먼트에 대해 4 개의 세그먼트 만 있습니다. 인텔 설명서를 읽는 동안 세그먼트가보다 강력한 솔루션을 염두에두고 설계되었다는 느낌을 받았습니다. 그런 다음 x86이 얼마나 복잡 할 수 있는지 여러 번 들었습니다.

나는 Linux에 대한 Linux Torvald의 원래 '발표'에 링크 된 후이 흥미로운 일화를 발견했습니다. 그는 이것을 몇 개의 포스트 후에 말했다 :

간단히 말해서 이식이 불가능하다고 말하고 싶습니다. 그것은 대부분 C 언어이지만 대부분의 사람들은 내가 C라고 부르는 것을 부르지 않을 것입니다. 그것은 386에 대해 가르쳐주는 프로젝트 였기 때문에 내가 찾은 386의 모든 가능한 기능을 사용합니다. 이미 언급했듯이 MMU를 사용합니다. 페이징 (아직 디스크 아님) 및 세분화 모두에 적용됩니다. 그것은 386에 의존하게 만드는 세분화입니다 (모든 작업에는 코드 및 데이터에 대한 64Mb 세그먼트가 있습니다-4Gb에서 최대 64 개의 작업. 64Mb / 작업-터프 쿠키가 필요한 사람).

내 자신의 x86 실험으로 인해이 질문을하게 된 것 같습니다. Linus에는 StackOverflow가 없었기 때문에이를 구현하기 위해 구현했습니다.

예를 들어 세그먼테이션을 사용하면 동적으로 할당 된 각 객체 (malloc)를 자체 메모리 세그먼트에 넣을 수 있습니다. 하드웨어는 세그먼트 제한을 자동으로 확인하고 모든 종류의 보안 버그 (버퍼 오버런)가 제거됩니다.

또한 모든 세그먼트 오프셋이 0에서 시작하므로 모든 컴파일 된 코드는 자동으로 위치 독립적입니다. 다른 DLL을 호출하면 호출 된 함수에 따라 일정한 오프셋을 가진 원거리 호출로 요약됩니다. 이렇게하면 링커와 로더가 크게 단순화됩니다.

4 개의 보호 링을 사용하면 더 세밀한 액세스 제어 (페이징을 통해 사용자 및 관리자의 2 가지 보호 수준 만 있음) 및보다 강력한 OS 커널을 고안 할 수 있습니다. 예를 들어 링 0 만 하드웨어에 완전히 액세스 할 수 있습니다. 핵심 OS 커널과 장치 드라이버를 링 0과 1로 분리하면 HW가 대부분의 관련 액세스 검사를 수행하는보다 강력하고 빠른 마이크로 커널 OS를 만들 수 있습니다. (장치 드라이버는 TSS의 I / O 액세스 비트 맵을 통해 하드웨어에 액세스 할 수 있습니다.)

그러나 .. x86은 약간 제한적입니다. "무료"데이터 세그먼트 레지스터는 4 개뿐입니다. 그것들을 다시로드하는 것은 다소 비싸며 동시에 8192 세그먼트에만 액세스 할 수 있습니다. 액세스 가능한 객체의 수를 최대화하려는 경우 GDT는 시스템 설명자와 LDT 설명 자만 보유합니다.

이제 64 비트 모드 세그먼트 화는 "레거시"로 설명되며 하드웨어 제한 검사는 제한된 환경에서만 수행됩니다. IMHO, 큰 실수. 사실 나는 인텔을 탓하지 않으며, 대부분 개발자를 탓한다. 대다수는 세분화가 "너무 복잡하다"고 평평한 주소 공간을 갈망했다고 생각했다. 또한 세분화를 잘 활용하려는 상상력이 부족한 OS 작가를 비난합니다. (AFAIK, OS / 2는 세그먼테이션 기능을 최대한 활용 한 유일한 운영 체제입니다.)

짧은 대답은 세분화가 해킹이며, 메모리를 처리하는 능력이 제한적인 프로세서가 이러한 한계를 초과하도록 만드는 데 사용됩니다.

8086의 경우 칩에 20 개의 주소 라인이 있었으므로 1Mb의 메모리에 물리적으로 액세스 할 수 있습니다. 그러나 내부 아키텍처는 8080과의 일관성을 유지하려는 의도로 인해 약 16 비트 어드레싱을 기반으로했습니다. 따라서 명령어 세트에는 16 비트 인덱스와 결합하여 1Mb의 전체 메모리 주소를 지정할 수있는 세그먼트 레지스터가 포함되었습니다. . 80286은 세그먼트 기반 보호 및 더 많은 메모리 주소 지정 (iirc, 16Mb)을 지원하기 위해이 모델을 진정한 MMU로 확장했습니다.

PDP-11의 경우, 프로세서의 이후 모델은 16 비트 주소 공간의 한계를 다시 지원하기 위해 명령 및 데이터 공간으로 분할을 제공했습니다.

세그먼테이션의 문제점은 간단합니다. 프로그램은 아키텍처의 한계를 명시 적으로 해결해야합니다. 8086의 경우 이는 액세스 할 수있는 가장 큰 연속 메모리 블록이 64k임을 의미합니다. 그 이상으로 액세스해야하는 경우 세그먼트 레지스터를 변경해야합니다. 이는 C 프로그래머에게 C 컴파일러에게 어떤 종류의 포인터를 생성해야하는지 알려 주어야한다는 것을 의미했습니다.

32 비트 내부 아키텍처와 24 비트 실제 주소 공간이있는 MC68k를 프로그래밍하는 것이 훨씬 쉬웠습니다.

80x86의 경우 "없음", 세그먼테이션 만, 페이징 만, 세그먼테이션과 페이징의 4 가지 옵션이 있습니다.

"아무것도"(세그먼트 또는 페이징 없음)의 경우 프로세스 자체를 보호하는 쉬운 방법, 프로세스를 서로 보호하는 쉬운 방법, 물리적 주소 공간 조각화와 같은 것을 처리 할 수있는 방법, 위치를 피할 수있는 방법이 없습니다. 독립 코드 등. 이러한 모든 문제에도 불구하고 (이론적으로) 일부 상황에서 유용 할 수 있습니다 (예 : 하나의 응용 프로그램 만 실행하는 내장 장치 또는 JIT를 사용하고 어쨌든 모든 것을 가상화하는 장치).

세그먼테이션에만 해당합니다. "프로세스 자체 보호"문제를 거의 해결하지만 프로세스가 8192 개 이상의 세그먼트 (프로세스 당 하나의 LDT를 가정)를 사용하려고 할 때 유용하게 만들려면 많은 해결 방법이 필요합니다. "서로 프로세스 보호"문제를 거의 해결합니다. 그러나 동일한 권한 수준에서 실행되는 다른 소프트웨어는 서로의 세그먼트를로드 / 사용할 수 있습니다 (제어 전송 및 / 또는 LDT 사용 중 GDT 항목 수정). 또한 대부분 "위치 독립적 인 코드"문제를 해결합니다 ( "세그먼트 종속 코드"문제를 일으킬 수 있지만 그 정도는 덜 중요합니다). "물리적 주소 공간 조각화"문제에 대해서는 아무 것도하지 않습니다.

페이징 전용; "프로세스 자체 보호"문제를 많이 해결하지는 못합니다. 그러나 여기서 솔직히 말하면 안전하지 않은 언어로 작성된 코드를 디버깅 / 테스트 할 때만 문제가됩니다. 어쨌든 valgrind와 같은 훨씬 강력한 도구가 있습니다. "서로 프로세스 보호"문제를 완전히 해결하고 "위치 독립적 인 코드"문제를 완전히 해결하며 "물리적 주소 공간 조각화"문제를 완전히 해결합니다. 추가 보너스로서 페이징 없이는 실용적이지 않은 매우 강력한 기술을 제공합니다. "쓰기시 복사", 메모리 매핑 파일, 효율적인 스왑 공간 처리 등을 포함합니다.

이제 세분화와 페이징을 모두 사용하면 두 가지 이점을 모두 얻을 수 있다고 생각할 것입니다. 이론적으로는 페이징을 통해 더 잘 수행되지 않는 세그먼테이션에서 얻을 수있는 유일한 이점은 아무도 신경 쓰지 않는 "프로세스 자체 보호"문제에 대한 솔루션이라는 점을 제외하고는 가능합니다. 실제로 당신이 얻는 것은 이점이 거의 없기 때문에 둘 다의 복잡성과 둘 다의 오버 헤드입니다.

이것이 80x86 용으로 설계된 거의 모든 OS가 메모리 관리를 위해 분할을 사용하지 않는 이유입니다 (CPU 및 작업 별 스토리지와 같은 용도로 사용하지만 대부분의 경우 범용 레지스터를 사용하지 않는 것이 편리함) 소지품).

물론 CPU 제조업체는 바보가 아닙니다. 아무도 사용하지 않는 것을 최적화하는 데 시간과 돈을 소비하지 않을 것입니다 (거의 모든 사람들이 대신 사용하는 것을 최적화 할 것입니다). 이러한 이유로 CPU 제조업체는 세그먼트 화를 최적화하지 않아 세그먼트 화 속도가 느려져 OS 개발자는이를 피하기를 원합니다. 대부분 이전 버전과의 호환성을 위해 세분화 만 유지했습니다 (중요).

결국 AMD는 장거리 모드를 설계했습니다. 걱정할 구식 / 존재하는 64 비트 코드는 없었으므로 (64 비트 코드의 경우) AMD는 최대한 많은 세그먼트를 제거했습니다. 이것은 OS 개발자들에게 세그먼테이션을 피할 수있는 또 다른 이유 (세그멘테이션을 위해 설계된 코드를 64 비트로 쉽게 포팅하는 방법이 없음)를 제공했습니다.

나는이 질문이 게시 된 이후로 아무도 세그먼트 메모리 아키텍처의 기원과 그들이 감당할 수있는 진정한 힘을 언급하지 않았다는 사실에 놀랐습니다.

세그먼트 화 된 페이징 된 가상 메모리 시스템 (대칭 다중 처리 및 계층 적 파일 시스템과 함께)의 설계 및 사용을 둘러싼 모든 기능을 유용한 형태로 발명하거나 개선 한 최초의 시스템은 Multics 였습니다 ( Multicians 사이트 참조 ). 세그먼트 메모리는 사용자에게보기를 제공 멀 틱스 수 있도록 모든 (가상) 메모리에, 그리고 그것의 공유의 궁극적 인 수준의 수 모든 것을직접 형식으로 (즉, 메모리에서 직접 주소 지정 가능) 파일 시스템은 단순히 메모리의 모든 세그먼트에 대한 맵이됩니다. 체계적인 방식으로 (Multics에서와 같이) 세그먼트 메모리를 올바르게 사용하면 2 차 스토리지 관리, 데이터 공유 및 프로세스 간 통신의 많은 부담으로부터 사용자를 해방시킬 수 있습니다. 다른 답변에 따르면 세그먼트 메모리가 사용하기가 더 어렵다는 손짓에 대한 주장이 있었지만 이것은 사실이 아니며 Multics는 수십 년 전에 성공을 거두었다는 것을 입증했습니다.

인텔은 80286의 강력한 분할 메모리 버전을 만들었 기 때문에 매우 강력하지만 그 한계로 인해 실제로 유용한 용도로는 사용할 수 없었습니다. 80386은 이러한 한계를 개선했지만 당시 시장의 힘은 이러한 개선 사항을 활용할 수있는 시스템의 성공을 거의 막았습니다. 그 이후로 너무 많은 사람들이 과거의 교훈을 무시하는 법을 배웠습니다.

인텔은 또한 이전 에는 다른 어떤 것을 능가 할 수 있는 iAPX 432 라고하는 더 유능한 슈퍼 마이크로 (super-micro)를 구축하려고 시도 했으며, 세그먼트 메모리 아키텍처와 객체 지향 프로그래밍을 향한 기타 기능을 갖추고있었습니다. 원래 구현은 너무 느 렸으며 더 이상 수정하려고 시도하지 않았습니다.

Multics가 세그먼트 및 페이징을 사용하는 방법에 대한 자세한 내용은 Paul Green의 논문 Multics Virtual Memory-Tutorial and Reflections에서 확인할 수 있습니다.

세분화는 16 비트 프로세서에서 최대 1MB의 메모리를 처리 할 수있는 해킹 / 해결 방법이었습니다. 일반적으로 64K의 메모리에만 액세스 할 수있었습니다.

32 비트 프로세서가 출시되면 플랫 메모리 모델을 사용하여 최대 4GB의 메모리를 처리 할 수 ​​있고 더 이상 세그먼트 화가 필요하지 않습니다. 세그먼트 레지스터는 보호 모드에서 GDT / 페이징에 대한 선택기로 용도가 변경되었습니다. 보호 모드가 16 비트 인 경우).

또한 플랫 메모리 모드는 컴파일러에 훨씬 편리 합니다. C로 16 비트 세그먼트 프로그램을 작성할 수 있지만 다소 번거 롭습니다. 플랫 메모리 모델은 모든 것을 더 단순하게 만듭니다.

ARM과 같은 일부 아키텍처는 메모리 세그먼트를 전혀 지원하지 않습니다. 리눅스가 세그먼트에 소스에 의존한다면, 그 아키텍처로 쉽게 포팅 될 수 없었을 것입니다.

더 넓은 그림을 보면, 메모리 세그먼트의 실패는 C의 인기와 포인터 산술과 관련이 있습니다. 플랫 메모리를 가진 아키텍처에서는 C 개발이 더 실용적입니다. 플랫 메모리를 원하면 메모리 페이징을 선택하십시오.

조직으로서 인텔이 미래의 Ada 및 기타 고급 프로그래밍 언어의 인기를 기대하고 있었을 때 80 년대가 바뀌 던시기가있었습니다. 이것은 기본적으로 끔찍한 APX432 및 286 메모리 세그먼테이션과 같은 더 화려한 실패의 일부입니다. 386으로 그들은 플랫 메모리 프로그래머들에게 항복했다. 페이징 및 TLB가 추가되었고 세그먼트는 4GB로 크기를 조정할 수있게되었습니다. 그리고 AMD는 기본적으로 기본 reg를 dont-care / implied-0으로 설정하여 x86_64로 세그먼트를 제거했습니다 (TLS에 대한 fs? 제외).

그러나 메모리 세그먼트의 장점은 TLB를 다시 채울 필요없이 주소 공간을 전환하는 것입니다. 언젠가 누군가가 세그먼트 화를 지원하는 성능 경쟁력있는 CPU를 만들고, 세그먼트 지향 OS를 프로그래밍하고, 프로그래머는 Ada / Pascal / D / Rust / 다른 언어를 만들 수 있습니다. 메모리 프로그램.

분할은 응용 프로그램 개발자에게 큰 부담입니다. 여기에서 세분화를 없애기 위해 큰 푸시가 시작되었습니다.

흥미롭게도 인텔이 이전 모드에 대한 모든 레거시 지원을 없애면 i86이 얼마나 더 나을지 궁금해합니다. 여기서 더 나은 것은 더 낮은 전력과 더 빠른 작동을 의미합니다.

인텔이 16 비트 세그먼트로 우유를시 워서 개발자 반란을 일으킨다 고 주장 할 수 있습니다. 그러나 64k 주소 공간은 현대적인 응용 프로그램을 볼 때 특히 아무것도 아닙니다. 결국 그들은 경쟁이 i86의 주소 공간 문제에 효과적으로 대응할 수 있고 효과적으로 시장에 내놓았 기 때문에 무언가를해야했습니다.

세분화로 인해 페이지 변환 속도가 느리고 전환

이러한 이유로 x86-64에서 세분화가 크게 감소했습니다.

그들 사이의 주요 차이점은 다음과 같습니다.

• 페이징은 메모리를 고정 된 크기의 덩어리로 나눕니다.
• 분할은 각 청크마다 다른 너비를 허용합니다

구성 가능한 세그먼트 너비를 갖는 것이 더 똑똑해 보일 수 있지만 프로세스의 메모리 크기를 늘리면 다음과 같은 조각화가 불가피합니다.

|   | process 1 |       | process 2 |                        |
     -----------         -----------
0                                                            max

프로세스 1이 커짐에 따라 결국에는

|   | process 1        || process 2 |                        |
     ------------------  -------------
0                                                            max

분할이 불가피 할 때까지 :

|   | process 1 part 1 || process 2 |   | process 1 part 2 | |
     ------------------  -----------     ------------------
0                                                            max

이 지점에서:

• 페이지를 변환하는 유일한 방법은 프로세스 1의 모든 페이지에 대해 이진 검색을 수행하는 것입니다. 허용되지 않는 log (n)
• 프로세스 1 파트 1의 스왑은 그 세그먼트가 클 수 있기 때문에 클 수 있습니다.

그러나 고정 크기 페이지의 경우 :

• 모든 32 비트 변환은 2 개의 메모리 읽기만 수행합니다. 디렉토리 및 페이지 테이블 워크
• 모든 스왑은 허용되는 4KiB입니다.

고정 크기의 메모리 덩어리는 더 관리하기 쉽고 현재 OS 디자인을 지배합니다.

참조 : https : //.com/questions/18431261/how-does-x86-paging-work