x86 PM 아키텍처에서 스와핑, 페이징, 세분화 및 가상 메모리


4

글쎄, 이것은 일반적이거나 이미 질문 된 것처럼 보일 수 있지만 다양한 서적, 온라인 자습서 및 심지어 SU에 대한 검색 후에도이 네 짐승이 x86 보호 모드 시스템에서 어떻게 작동하는지 여전히 의아해합니다.

이러한 것들에 대해 논의 할 때 사용할 수있는 올바른 용어는 무엇입니까?

내가 이해하는 한이 4 가지 개념은 완전히 다르지만 메모리 보호에 대해 이야기 할 때 관련이 있습니다. 이것은 나를 위해 엉망이 된 곳입니다!

먼저 스와핑부터 시작하겠습니다.

스와핑 :

프로세스는 실행을 위해 실제 메모리에 있어야합니다. 프로세스는 물리적 메모리에서 일시적으로 백업 저장소로 스왑 한 다음 계속 실행되도록 메모리로 다시 가져올 수 있습니다.

이는 특히 여러 프로세스를 동시에 실행해야하는 멀티 태스킹 환경에 적용되므로 CPU 스케줄러가 구현되어 백업 저장소로 교체 할 프로세스를 결정합니다.

페이징 : 일명 간단한 페이징 :

예를 들어, 프로세스가 0-16MB 범위의 모든 주소를 사용한다고 가정 해 봅시다. 주소가 프로세스에 의해 생성 되므로 프로세스논리 주소 공간 이라고 할 수 있습니다 .

이 정의에 따르면 프로세스의 논리 주소 공간은 프로세스가 크거나 작을 수 있으므로 다른 프로세스의 논리 주소 공간과 다를 수 있습니다.

이제 프로세스의이 논리 주소 공간을 페이지 라고하는 동일한 크기의 블록으로 나눕니다 . 또한 물리적 메모리를 프레임 이라는 고정 크기 블록으로 나눕니다 .

데프. 논리 주소 = page # : 해당 페이지의 오프셋

프로세스가 CPU 스케줄러에 의해 실행되도록 선택되면 해당 페이지는 백업 저장소에서 사용 가능한 메모리 프레임 으로로드됩니다 .

참고 모든 컨트롤이 스케줄러에서이 프로세스에 옮겨진 전에이 과정에 속하는 페이지가 메모리에로드됩니다. 이 프로세스를 백업 저장소로 바꾸려면 모든 페이지가 백업 저장소에 저장됩니다.

백업 저장소는 실제 메모리 프레임과 동일한 크기의 고정 크기 블록으로 나뉩니다.

바이트가 아닌 페이지를 스왑 할 때 스왑 프로세스가 쉬워집니다. 일부 바이트에 대한 공간을 찾을 필요가 없기 때문에 백업 저장소에서 조각화가 줄어드는 대신 페이지에 사용 가능한 공간이 있는지 확인합니다.

페이징 기술은 또한 페이지를 메모리에 유지함에 따라 물리적 메모리의 조각화를 줄입니다.

실행을 위해 메모리에 해당 프로세스를로드 하려면 기본 메모리 에는 프로세스에 속하는 모든 페이지를 위한 공간이 있어야합니다 . 이 프로세스의 몇 페이지에 대해서만 공간이있는 경우 다른 프로세스 (예 : 프로세스에 속하는 모든 페이지)를 백업 저장소로 교체 한 다음 실행할 프로세스의 모든 페이지 만 메모리에로드해야합니다.

따라서 페이징 기술은 단순한 스와핑보다 더 나은 성능을 제공합니다.

따라서 스와핑을 통해 너무 많은 메모리를 구매하지 않고도 여러 프로세스를 실행할 수 있습니다. 대신 적은 양의 메모리로 작업 할 수 있습니다 (이 크기는 가장 큰 프로그램 / 프로세스의 모든 페이지가 PC에서 실행되도록해야합니다) 메모리에로드 할 수 있습니다. 즉, 프로그램을 실행하기 전에 프로그램에 필요한 메모리 양을 알아야합니다.) 추가 백업 저장소 (일반적으로 디스크)는 주 메모리보다 훨씬 큰 용량에 비해 비용이 훨씬 적게 듭니다.

따라서 스와핑 + 페이징을 통해 메모리를 효율적으로 관리 할 수 ​​있으므로 시스템에서 여러 프로세스를 실행할 수 있습니다.

수요 페이징 :

그러나 시스템에 설치된 실제 메모리는 프로세스 요구 사항과 같을 필요는 없습니다. 또한 여러 프로세스를 실행해야합니다.

해결책은 프로세스의 일부 페이지 만 메모리 에로드 하는 것입니다. 프로세스 가 메모리에없는 페이지의 주소에 액세스하면 페이지 오류가 발생하고 요청시 OS가 해당 페이지 로드 하여 프로세스를 계속 실행할 수 있습니다. . 따라서 페이징 + 스와핑과 마찬가지로 제어를 전송하기 전에 해당 프로세스의 모든 페이지를로드하는 시간이 절약됩니다.

프로세스의 일부만 메모리에 유지하고 디스크와 같은 백업 저장소에있는이 기술을 요구 페이징 이라고 합니다.

따라서 수요 페이징 = 페이징 + 스와핑 + 프로세스의 일부 페이지 만 메모리에 유지합니다.


이것은 내가 아는 페이징 및 스왑에 관한 것입니다. 위의 어딘가에 내가 틀렸다는 것을 수정하십시오.

이제 내 질문은 :

  1. x86 보호 모드와 관련하여 가상 메모리 및 가상 주소 공간 (일명 선형 주소 공간) 용어가 수요 페이징과 정확히 관련되는 방법

  2. "프로세스의 가상 메모리"가 올바른 용어 입니까, 아니면 멀티 태스킹 시스템에서 현재 실행중인 모든 프로세스에 대해 가상 메모리가 정의되어 있습니까?

  3. 프로세스에 사용할 수있는 가상 메모리 == 프로세스의 가상 주소 공간 (일명 선형 주소 공간)에서 가장 높은 주소 + 1?

  4. x86 보호 모드에서는 각 프로세스에 4GB VAS (가상 주소 공간)가있을 수 있다는 메시지가 나타납니다. 즉, x86 아키텍처에 세그먼테이션 이 있으므로이 VAS 를 둘 이상의 세그먼트로 나눌 수 있습니다. . x86 Flat 모델에서, 프로세스의 VAS에 세그먼트가 모두 정확하게 겹치므로 세그먼트가 효과적으로 비활성화되므로 세그먼트가 없습니다. 그러나 일부 프로세스의 VAS의 가상 주소에서 일부 CPU 명령어가 존재하면 메모리를 할당하거나 (이 VAS에서) 변수 또는 배열을 만들 때 이러한 명령어를 덮어 쓸 수 있습니다. 이런 일이 발생하지 않도록 어떻게해야합니까? 디스크립터의 보호 비트는 플랫 모드에서 모든 세그먼트가 겹치는 영역을 흑백으로 구분하지 않습니다. 이 비트는 코드를 읽거나 데이터를 실행하는 것을 막을뿐 아니라 세그먼트를 통해 셀렉터를 통해 액세스 할 수 있습니다.

  5. 또는 각 세그먼트가 자체 VAS로 취급되는 것과 같은 것입니까? 그러나이 경우 플랫 모드에서 프로세스사용 가능한 총 가상 메모리 (또는 총 VAS) 는 "단일 세그먼트의 프로세스 x 가상 메모리에 속하는 세그먼트 수"입니다. x86 보호 모드의 경우 이는 6 x 4GB = 24GB의 VAS로 변환됩니다! CS, DS, ES, GS, FS, SS 레지스터가 가리키는 6 개의 세그먼트를 가정합니다. 이 올바른지 ?

  6. 가상 메모리가 아닌 단순 페이징 (요청 페이징은 아님)을 지원하는 환경은 플랫 메모리 모델에서 다양한 세그먼트의 보호를 어떻게 보장합니까? 여기에는 단일 작업 시스템과 다중 작업 시스템이라는 두 가지 경우가 있습니다.

업데이트 : 2012-07-29

그래서 내가 올바르게 이해하면 :

가상 메모리는 개념 이며 수요 페이징 기술과 일부 보호 비트 (특히 U 비트 및 W 비트) 사용하여 x86 아키텍처에서 구현 됩니다 .

프로세스의 VAS 인 IOW는 페이지나뉘어 수요 페이징에 사용됩니다.

가상 메모리 메커니즘은 기본적으로 멀티 태스킹 환경에서 두 가지 용도로 사용 됩니다.

  1. 프로그램 크기가 사용 가능한 실제 메모리 양을 초과 할 수 있습니다. 운영 체제는 현재 사용중인 프로그램 부분을 주 메모리에, 나머지 부분은 디스크에 보관합니다. 이는 페이지 테이블 항목에 '현재 비트'및 '액세스 된 비트'와 연관된 각 페이지가있는 요청 페이징에 의해 구현됩니다.

  2. 각 프로세스에 고유 한 가상 주소 공간을 제공하여 한 프로세스가 다른 프로세스의 VAS에 액세스 할 수 없도록 하여 메모리를 보호합니다 . 이것은 각 페이지와 관련된 보호 비트를 가짐으로써 구현됩니다 . 특히 페이지 테이블 항목의 '사용자 / 감독자 비트-U 비트', 읽기 / 쓰기 비트 W 비트 '는 페이지 액세스 보호에 사용 됩니다.

가상 메모리는 단일 태스킹 시스템과 다중 태스킹 시스템 모두에 유용 합니다. 단일 작업 시스템의 경우 Use # 1 관련됩니다.

페이지 액세스 보호는 두 측면이있다 : privledge 수준의 보호보호를 쓰기 . 이들은 각각 U 비트 (사전) 및 W 비트 (쓰기)로 구현됩니다. 이 비트는 해당 페이지의 페이지 테이블 항목에 있습니다.

메모리 보호에는 두 가지 측면이 있습니다 . 프로그램이 서로 액세스하지 못하도록 보호하고 세그먼트가 해당 프로세스 / 프로그램의 VAS에서 겹치는 경우 프로그램이 자신덮어 쓰지 않도록 보호합니다 .

이제 이전 문제는 VAS 또는 가상 메모리 개념으로 해결되었지만 후자의 경우는 어떻습니까?

페이지 액세스 보호 체계 내가 아는 한 후자를 보호 하지 않습니다 . IOW (가상 메모리 기술)는 세그먼트가 프로세스의 VAS에서 겹치는 경우에 프로그램이 자체를 덮어 쓰는 것을 막지 않습니다.

그러나 세그먼트 레벨 보호조차도 메모리 보호의 후자 (덮어 쓰기 자체) 문제를 막을 수는없는 것 같습니다 .

x86 CPU 는 x86 CPU에서 분할을 비활성화 할 수있는 방법이 없으므로 플랫 또는 다중 세그먼트 모델인지 여부에 관계없이 페이지 수준 보호 검사 수행 하기 전에 항상 세그먼트 수준 보호 평가합니다 .

플랫 모델 시나리오를 고려하십시오.

CS : off가 참조하는 가상 주소를 고려하십시오. 이제 두 경우 모두 'off'값이 정확히 동일한 경우 DS : off는 CS : off에서 참조한 것과 동일한 가상 주소 를 참조합니다. SS : off도 마찬가지입니다.

또한 가상 / 선형 주소가있는 페이지는 페이징 단위에서 세그먼트 화에 대해 알지 못하는 단순한 페이지로 간주됩니다.

플랫 모드에서 프로그램의 모든 세그먼트가 ring0과 같은 동일한 권한 레벨에 속한다고 가정하십시오.

이제 CS : off = DS : off = SS : off에서 데이터를 쓰거나 실행하려고하면 어떻게됩니까?

이 주소가 프로세스의 VAS에 매핑 된 OS 코드에 속하지 않는다고 가정합니다. 간단히하기 위해 OS를 따로 보관 해 두십시오. 하드웨어 수준의 보호에 대해 이야기하고 있습니다!

모든 세그먼트로에 속하는 첫째, 세그먼트 수준의 보호가 전달됩니다 다음, 권한 수준 점검이 페이지에 액세스 (: 끄거나 DS : 꺼져 있거나 SS 오프 CS가 포함 된 페이지) 동안 전달됩니다 같은 특권 여기에,하지만에 대한 이 페이지의 W 비트. 쓰기를 허용하려면 1로 설정해야합니다. 그렇지 않으면 데이터 세그먼트가 자신의 페이지에서 쓰기를 수행 할 수 없습니다. 따라서 이것은이 페이지도 쓸 수 있음을 의미합니다.

즉,이 가상 (선형) 주소에서 데이터를 읽거나 쓰거나 실행할 수 있습니다. CS : off = DS : off = SS : off.?

세그먼트가 겹치는 경우 x86 하드웨어가이 문제를 어떻게 보호 할 수 있는지 이해하지 못합니다 .

답변:


3

알았을 것입니다. 많은 용어가 날아 다니고 혼란 스러웠지만 대답하기 위해 최선을 다하겠습니다. 내가 당신에게 말할 수있는 한, 당신의 대부분의 이해에있어 정확하지만, 극복해야 할 몇 가지 사항이 있습니다.

페이징 및 가상 메모리가 하드웨어 컨텍스트에서 작동하는 방식을 이해하는 것이 중요합니다. 프로세스는 메모리 배치 방법에 대해 불가지론 적이어야하고 운영 체제가 소프트웨어를 사용하여 시스템의 모든 프로세스를 보모하지 않아도되므로 페이징은 하드웨어 지원 없이는 비실용적입니다. 메모리 관리 장치 (MMU)가 들어온 곳입니다.이 장치는 기본적으로 가상 주소 공간에 페이지를 정렬하도록 운영 체제에 의해 프로그래밍되며 운영 체제에 의해 임의로 제어 될 수 있습니다. 운영 체제는 실제 RAM에있는 페이지와 아직로드되지 않았거나 스왑 된 페이지를 장치에 알릴 수 있습니다.

그렇다면 어떻게 프로그램이이 메모리 관리를 방해하지 않게 할 수 있습니까? 우리는 보호라고 부릅니다. 우리는 프로세스를 운영 체제 및 기타 프로세스와 상호 작용하지 않도록 샌드 박스로 유지할 수 있습니다. 이러한 용어가 모두 함께 사용되는 이유에 대한 혼란은 이들이 실제로 서로 연결되어 있다는 사실에서 비롯됩니다. 코드가 가진 특기는 페이지 테이블에 의해 지정됩니다. 페이지 테이블은 MMU에 가상 공간이 배치되는 방법을 알려주고 페이지가 A) 있는지 여부 B) 읽기 / 쓰기 C) 코드를 실행할 수 있는지 D) 코드에 대한 권한 수준 (링) 상기 페이지는 실행될 수있다.

스케줄러가 프로세스를 스케줄 할 때 페이지 테이블을 다시 작성하지 않고 새 메모리를 배열 할 필요가 없으며 운영 체제는 단순히 MMU에게 다른 페이지 테이블 (O (1) 프로세스)을 사용하도록 지시합니다. 프로세스의 크기 나 사용하는 메모리 양에 의존하지 않습니다. 전체 프로세스가 메모리에서 한 번에 거의 스왑 및 스왑되는 경우는 거의 없습니다. 일반적으로 한 번에 한 페이지 일 뿐이므로 "스와핑"이라는 용어는 종종 "페이지 스와핑"으로 명시됩니다.

자, 그 배경으로, 나는 당신의 각 질문에 대답하려고 노력할 것입니다.

  1. 선형 주소 공간은 단순히 0에서 2 ^ 32 사이의 항목에 액세스 할 수 있음을 의미합니다. 16 비트 프로세서 시대에 필요한 고급 분할이 필요하지 않습니다. 가상 메모리는 단순히 프로세스의 선형 주소 공간이 주 메모리가 아니라 운영 체제에 의해 정의됨을 의미합니다. 이는 운영 체제가이 주소 공간에 임의로 페이지를 정렬하여 높은 수준으로 프로세스를 배치 할 수 있음을 의미합니다. 예를 들어 또한 프로세서는이 가상 주소 공간의 어떤 부분이 어떤 권한으로 액세스 가능한지 지정할 수 있습니다. 운영 체제 (커널)는 모든 가상 주소 공간에로드되므로 프로세스가 시스템 호출을 수행 할 수 있으며 선점시 이동할 곳이 있습니다. 그러나 OS에서 "권한이있는 코드 만"으로 표시되어 있기 때문에이 영역을 읽거나 쓸 수 없습니다. 요구 페이징은 단순히 프로세스가이 가상 주소 공간의 특정 부분에 특정 내용 (아마도 파일 또는 그 자체)이있을 것으로 예상하지만 실제로는 존재하지 않으므로 OS가 페이지 표에 "존재하지 않음"영역을 표시했습니다. . 프로세스가이 영역에 최종적으로 액세스 할 때,이 영역이 없기 때문에 CPU는 OS에 의해 갇힌 결함을 발생시킵니다. 그런 다음 OS는 해당 페이지를로드하고 중단 된 프로세스를 다시 시작하기에 충분합니다. 결과적으로 프로세스는 딸꾹질을 인식하지 못하고 요구되는 대로만로드되어 메모리를 절약 할 수 있습니다. 요구 페이징은 단순히 프로세스가이 가상 주소 공간의 특정 부분에 특정 내용 (아마도 파일 또는 그 자체)이있을 것으로 예상하지만 실제로는 존재하지 않으므로 OS가 페이지 표에 "존재하지 않음"영역을 표시했습니다. . 프로세스가이 영역에 최종적으로 액세스 할 때,이 영역이 없기 때문에 CPU는 OS에 의해 갇힌 결함을 발생시킵니다. 그런 다음 OS는 해당 페이지를로드하고 중단 된 프로세스를 다시 시작하기에 충분합니다. 결과적으로 프로세스는 딸꾹질을 인식하지 못하고 요구되는 대로만로드되어 메모리를 절약 할 수 있습니다. CPU가 존재하지 않기 때문에 CPU는 OS에 의해 잡힌 오류를 발생시킵니다. 그런 다음 OS는 해당 페이지를로드하고 중단 된 프로세스를 다시 시작하기에 충분합니다. 결과적으로 프로세스는 딸꾹질을 인식하지 못하고 요구되는 대로만로드되어 메모리를 절약 할 수 있습니다. CPU가 존재하지 않기 때문에 CPU는 OS에 의해 잡힌 오류를 발생시킵니다. 그런 다음 OS는 해당 페이지를로드하고 중단 된 프로세스를 다시 시작하기에 충분합니다. 결과적으로 프로세스는 딸꾹질을 인식하지 못하고 요구되는 대로만로드되어 메모리를 절약 할 수 있습니다.

  2. 가상 메모리는 페이지 테이블 및 계층 보호를 지정하고 페이지가 디스크와 같은 다른 매체에있을 수 있도록 페이징하는 전체 메커니즘의 이름입니다. 가상 메모리는 아마 세분화를 제외하고 타이틀의 포괄적 인 용어 일 것입니다. 특정 프로세스를 언급 할 때 개인적으로 "프로세스의 가상 주소 공간"과 같은 것을 개인적으로 사용합니다. 그 이유는 특정 프로세스의 가상 메모리 레이아웃을 명확하게 참조하기 때문입니다.

  3. 앞서 언급했듯이 OS는 프로세스의 가상 주소 공간에서 임의의 위치에 실제 메모리를 임의로 매핑 할 수 있습니다. 즉, 예를 들어 프로세스 코드가 주소 0x0에 있지만 힙 (증가)이 0xFFFFFFF에서 시작하여 주소 공간의 다른 쪽이 지워지는 상황이 발생할 수 있습니다. 하드웨어에 특정 주소 영역을 필요로하는 장치 드라이버로 인해 사물이 매핑되는 위치에는 실제로 제약이있을 수 있지만 가상 메모리를 이해하기 위해서는 제한이 없습니다.

  4. 세분화는 단순히 주소 지정 체계입니다. 286에서는 보호를 구현하는 메커니즘으로도 사용되었지만 너무 융통성이없는 것으로 입증되었으므로 32 비트 프로세서에서는 항상 페이징으로 보호가 수행됩니다. 비활성화 됨). 보호는 페이징 메커니즘에 의해 정의되므로 분할은 플랫 메모리 모드에서보다 데이터를 덮어 쓸 위험이 없습니다. 대부분의 실행 파일 형식을 사용하면 코드 세그먼트가 데이터 세그먼트와 명확하게 분리됩니다. 코드가 절대 변경되지 않을 것으로 예상 할 수 있으므로 운영 체제는 일반적으로 코드 세그먼트의 페이지를 읽기 전용으로 표시하므로 코드에 쓰려고하면 오류가 발생하고 프로그램이 종료됩니다. 모든 운영 체제에서 스택 또는 힙을 통해 모든 변수 및 배열이 할당 된 경우에는 발생하지 않습니다. 그러나 프로그램이이 밖에서 파고 들기 시작하면 코드를 덮어 쓰기 전에 충돌이 발생합니다. 더 큰 위험 (그리고 큰 문제로 사용되는 위험)은 스택 오버런으로 스택을 덮어 쓰는 것입니다. 일부는이를 활용하여 코드를 스택에 넣은 다음 무단으로 실행되도록 할 수 있습니다. 수정으로 새 비트가 페이지 테이블 "No eXecute"(NX) 비트에 배치되었습니다. 이렇게하면 페이지가 실행되지 않습니다. 일부는이를 활용하여 코드를 스택에 넣은 다음 무단으로 실행되도록 할 수 있습니다. 수정으로 새 비트가 페이지 테이블 "No eXecute"(NX) 비트에 배치되었습니다. 이렇게하면 페이지가 실행되지 않습니다. 일부는이를 활용하여 코드를 스택에 넣은 다음 무단으로 실행되도록 할 수 있습니다. 수정으로 새 비트가 페이지 테이블 "No eXecute"(NX) 비트에 배치되었습니다. 이렇게하면 페이지가 실행되지 않습니다.

  5. 이것은 사실이 아닙니다. 세그먼트는 단순히 원래 2 ^ 32 바이트의 주소 공간 영역 (세그먼트)에 대한 포인터 역할을합니다. 이 뒤에 숨겨진 아이디어는 포인터를 작게 유지하는 것이 었습니다. 세그먼트 포인터와 해당 세그먼트 내부에 전체 주소 공간보다 작은 포인터를 가질 수 있기 때문입니다. 예를 들어, 286 (16 비트 프로세서)에서는 포인터를 16 비트로 유지하는 것이 합리적이지만 286은 2 ^ 24 바이트의 메모리를 처리 할 수 ​​있기 때문에 문제가되었습니다. 해결책? 세분화를 사용하십시오. 세그먼트는 2 ^ 16 바이트 일 수 있으며 주소 공간의 아무 곳이나 가리킬 수 있습니다. 그런 다음 코드가 작동해야 할 때 해당 세그먼트 내에서만 16 비트 포인터를 사용합니다. 이것은 더 빠르고 효율적이었습니다. 32 비트 프로세서가 나왔을 때이 메커니즘은 더 이상 필요하지 않았습니다. 그러나 코드에 의해 너무 많이 사용되었고 프로그래머들이 그들에게 익숙했기 때문에 분할을 유지했습니다. 최신 64 비트 프로세서는 세그먼트 화를 전혀 사용하지 않습니다.

  6. 여기서 혼동은 가상 메모리가 여러 가지 다른 메커니즘의 용어라는 사실입니다. 한 프로세스를 다른 프로세스 주소 공간으로부터 보호하려면 멀티 태스킹에 가상 메모리가 필요합니다. 페이징 및 확장 성 선점 형 멀티 태스킹은 가상 메모리 기능에서만 가능합니다. 그러나 이러한 기능 중 많은 기능을 효과적으로 비활성화 할 수 있습니다. 아마도 당신은 주소 변환을 원하지 않습니까? 그런 다음 모든 페이지를 자체에 맵핑하십시오. 아마도 당신은 메모리 보호를 원하지 않지만 주소 변환을 원합니까? 그런 다음 모든 페이지에 모든 권한을 부여하십시오. DOS 및 기타 단일 프로세서 시스템에서 "보호 모드"를 참조하면 혼동이 발생합니다. 일반적으로 이것은 16 비트 실제 모드와 반대로 32 비트 모드를 참조하므로 이름에도 불구하고 반드시 보호가 사용된다는 의미는 아니며 해당 모드에서만 활성화 할 수 있습니다. 이 "보호 모드"에서 실행되지만 가상 메모리 나 보호를 사용하지 않는 단일 프로세스 시스템이 많이있을 수 있습니다. Xbox 1이 그 좋은 예입니다. 이러한 기능을 모두 비활성화하면 성능이 약간 향상 될 수 있습니다. 그러나 DOS에서는 이러한 많은 기능을 사용하는 것이 여전히 유리할 수 있습니다. 가장 주목할만한 점은 페이지 스와핑입니다. DOS가 언제 어디서나 사용되기 시작했을 때, RAM은 사용하기 어려웠으며, 따라서 RAM에 저장된 모든 메커니즘은 환영 받고 잘 사용되었습니다. 보호는 단일 프로세스 시스템에서도 장점이있었습니다. 프로그램이 추악한 방식으로 충돌하는 것을 방지하고 더 나은 디버깅을 가능하게하며 잘못된 하드웨어 액세스로 인한 데이터 손상을 방지 할 수 있기 때문입니다. 가상 메모리 나 보호를 사용하지 마십시오. Xbox 1이 그 좋은 예입니다. 이러한 기능을 모두 비활성화하면 성능이 약간 향상 될 수 있습니다. 그러나 DOS에서는 이러한 많은 기능을 사용하는 것이 여전히 유리할 수 있습니다. 가장 주목할만한 점은 페이지 스와핑입니다. DOS가 언제 어디서나 사용되기 시작했을 때, RAM은 사용하기 어려웠으며, 따라서 RAM에 저장된 모든 메커니즘은 환영 받고 잘 사용되었습니다. 보호는 단일 프로세스 시스템에서도 장점이있었습니다. 프로그램이 추악한 방식으로 충돌하는 것을 방지하고 더 나은 디버깅을 가능하게하며 잘못된 하드웨어 액세스로 인한 데이터 손상을 방지 할 수 있기 때문입니다. 가상 메모리 나 보호를 사용하지 마십시오. Xbox 1이 그 좋은 예입니다. 이러한 기능을 모두 비활성화하면 성능이 약간 향상 될 수 있습니다. 그러나 DOS에서는 이러한 많은 기능을 사용하는 것이 여전히 유리할 수 있습니다. 가장 주목할만한 점은 페이지 스와핑입니다. DOS가 언제 어디서나 사용되기 시작했을 때, RAM은 사용하기 어려웠으며, 따라서 RAM에 저장된 모든 메커니즘은 환영 받고 잘 사용되었습니다. 보호는 단일 프로세스 시스템에서도 장점이있었습니다. 프로그램이 추악한 방식으로 충돌하는 것을 방지하고 더 나은 디버깅을 가능하게하며 잘못된 하드웨어 액세스로 인한 데이터 손상을 방지 할 수 있기 때문입니다. DOS에서는 이러한 많은 기능을 사용하는 것이 여전히 유리할 수 있습니다. 가장 주목할만한 점은 페이지 스와핑입니다. DOS가 언제 어디서나 사용되기 시작했을 때, RAM은 사용하기 어려웠으며, 따라서 RAM에 저장된 모든 메커니즘은 환영 받고 잘 사용되었습니다. 보호는 단일 프로세스 시스템에서도 장점이있었습니다. 프로그램이 추악한 방식으로 충돌하는 것을 방지하고 더 나은 디버깅을 가능하게하며 잘못된 하드웨어 액세스로 인한 데이터 손상을 방지 할 수 있기 때문입니다. DOS에서는 이러한 많은 기능을 사용하는 것이 여전히 유리할 수 있습니다. 가장 주목할만한 점은 페이지 스와핑입니다. DOS가 언제 어디서나 사용되기 시작했을 때, RAM은 사용하기 어려웠으며, 따라서 RAM에 저장된 모든 메커니즘은 환영 받고 잘 사용되었습니다. 보호는 단일 프로세스 시스템에서도 장점이있었습니다. 프로그램이 추악한 방식으로 충돌하는 것을 방지하고 더 나은 디버깅을 가능하게하며 잘못된 하드웨어 액세스로 인한 데이터 손상을 방지 할 수 있기 때문입니다.

이것이 귀하의 질문에 답변되기를 바랍니다.


좋아지고있어 :) 그러나 Q # 4 및 Q # 6에 대한 답변을 얻지 못했습니다. Q # 4에 대해서는 2012-07-29의 내 업데이트를 참조하십시오. Q # 6에 관한 한, 일부 DPMI 환경 (ring0에서 응용 프로그램을 실행하고 자체적으로 순수한 DOS에서 실행되는 환경)이 가상 메모리를 지원하지 않지만 페이징을 지원 한다고 becoz에게 물었습니다 . DOS와 같은 단일 작업 환경이 시스템에있는 경우 특히 페이징이 유용한 경우를 얻지 못했습니까?
jacks

@ jacks 나는 그 질문에 더 잘 대답하고 대답하기 위해 응답을 수정했습니다. 짧은 버전은 다음과 같습니다. 코드 페이지를 읽기 전용으로 만들어 코드 덮어 쓰기를 방지합니다. DPMI는 항상 보호 또는 페이징이 활성화되어 있지는 않지만 메모리를 절약하고 끔찍한 충돌을 방지하기 위해 사용되기도합니다.
Dougvj

즉, 가상 메모리를 구현하지 않고 페이징은 쓸모가 없습니다. 그렇지 않습니까? "세그먼트가 겹치는 경우 x86 하드웨어가이 문제에 대한 보호 기능을 제공 할 수 있습니다" 와 관련하여 OS 지원이없는 것 같습니다. 예를 들어 OS없이 ring0에서 프로그램을 실행하는 것처럼 보입니다. 즉, 애플리케이션은 앱과 같은 커널입니다. x86 하드웨어에는 데이터 를 실행 하고 코드 세그먼트 에 쓰지 못하게 할 수있는 것이 없습니다 . x86 하드웨어 지원과 함께이를 만족시키지 못하는 OS입니다. 내가 맞아?

맞습니다. ring0 앱이 OS처럼 작동하고이를 방지하기 위해 올바른 보호 메커니즘을 설정할 수는 있지만 실제 보안이 아닌 디버깅에만 유용합니다. 페이지 스와핑은 메모리 절약에 유용하지만 단일 앱에 구현하는 것은 쉽지 않습니다.
Dougvj

알았다. :)이 주제에 대해 더 연구하고 혼란스러워 기다리고있는 것이 있는지 살펴 보겠습니다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.