가상 메모리를 끄더라도 컴퓨터 성능이 향상되지 않는 이유는 무엇입니까?

컴퓨터 아키텍처, 특히 가상 메모리를 연구하고 있습니다. 이해할 수없는 것 중 하나는 가상 메모리를 끄 더라도 컴퓨터 성능이 향상되지 않는 이유 는 무엇 입니까?

가상 메모리를 비활성화하는 데 몇 가지 단점이 있다는 것을 알고 있습니다 (예 : Windows는 충돌 덤프를 만들 수 없음). 시스템 속도를 높여서는 안됩니까?

가상 메모리를 사용하는 경우 RAM에 액세스 할 때마다 내 가상 주소를 하드웨어 주소로 변환하려면 MMU 에서 주 메모리 (또는 적어도 TLB )에 다시 액세스해야합니다 (오른쪽?).

따라서 RAM이 충분하다고 가정하면 가상 메모리를 비활성화하면 메모리에 대한 추가 액세스가 차단되어 더 이상 주소를 가상에서 물리적으로 변환 할 필요가 없으므로 시스템 속도가 빨라지지 않아야합니까?

가상 메모리는 페이지 파일 그 이상입니다.

시스템이 메모리를 디스크로 푸시 할 수 있도록하는 저장 장치를 간단히 제거했으며 최신 운영 체제에서 가상 메모리를 "단지"비활성화 할 수 없습니다.

운영 체제는 가상 메모리를 사용하여 응용 프로그램을 자체 주소 공간으로 분리하여 보안을 강화합니다.

응용 프로그램에 고유 한 주소 공간을 제공함으로써 모든 응용 프로그램은 메모리 영역에 대한 다른 응용 프로그램과 싸울 필요없이 전체 주소 범위에 액세스 할 수 있습니다.

메모리 분리 및 COW (Copy-On-Write) 보호는 두 응용 프로그램이 동일한 라이브러리를 공유하고 거의 동일한 코드 세트를 사용하지만 서로 완전히 보호됨을 의미합니다. 하나의 프로그램이 충돌하거나 무언가를 수행하면 다른 프로그램도 죽지 않을 것입니다.

시스템은 최신 운영 체제 설계의 핵심 구성 요소이므로 항상 가상 메모리를 사용합니다.

가상 메모리를 끄더라도 컴퓨터 성능이 향상되지 않는 이유는 무엇입니까?

Windows에서이 작업을 수행 할 때 실제로 수행하는 작업은 페이지 파일을 비활성화하는 것 입니다. OS에 더 이상 사용하지 않는 페이지를 디스크에 일시적으로 할당한다고 생각하는 것을 더 이상 제거하지 않아야한다고 OS에 알립니다.

디스크와 달리 RAM에서 많이 사용되지 않을 수있는 항목을 유지하기 때문에 실제로 컴퓨터 속도가 느려질 수 있습니다.

MMU를 비활성화하지 않습니다. MMU는 시스템이 프로세스 분리, 페이지의 데이터가 코드로 실행되는 것을 방지하는 "NX"기능 및 기타 기능을 구현하기 위해 시스템이 보호 모드에서 실행되는 동안 항상 사용되고 필요합니다.

모든 메모리 액세스는 온칩 기능보다 느립니다. 이것은 RISC 유형 CPU가 개발 될 때 고려해야 할 사항 중 하나입니다. RAM에 액세스 할 수 없도록 칩에 많은 레지스터를 배치하십시오.

AMD64 CPU에서 도입 된 개선 사항 중 하나는 레지스터를 추가하는 것이므로 RAM을 스크래치 패드로 사용하지 않고도 더 많은 작업을 수행 할 수 있습니다. 최신 CPU에는 매우 광범위한 SIMD / AVX / EVEX 레지스터도 있습니다. 최신 x86 CPU에서 계산하기위한 비 RAM 옵션이 많이 있습니다.

어쨌든 CPU RAM 액세스는 비활성화되지 않는 한 내부 L1 캐시를 먼저 활용하므로 문자 그대로 CPU와 동일한 다이에 있기 때문에 매우 빠릅니다.

MMU / TLB를 비활성화하여 얻는 속도는 매우 작으며 다른 프로세스로부터 메모리를 보호 할 수 없습니다.

Windows, Mac 또는 Linux 등 운영 체제의 가상 메모리 관리보다 성능이 우수하지 않습니다.

OS는 절대적으로 필요한 경우가 아니면 데이터를 페이지 / 스왑 파일에 저장하지 않습니다. 페이지 파일이 백그라운드에서 필요한 경우에만 사용되므로 페이지 파일을 활성화하면 성능에 영향을 미치지 않아야합니다.

컴퓨터가 페이지 / 스왑 파일을 자주 쳐서 컴퓨터 속도가 느려지고 도움이되지 않으면 RAM이 부족할 때 응용 프로그램이나 OS가 중단됩니다.

또한 페이지 / 스왑 파일을 비활성화해도 "가상 메모리"는 비활성화되지 않습니다. 가상 메모리는 페이징 / 스와핑을 허용하는 메모리 주소 지정 개념이지만 페이지 파일 사용 여부에 관계없이 여전히 사용됩니다.

인텔 CPU는 두 가지 주소 지정 모드에서 실행될 수 있으며 이들 사이를 전환 할 수 있습니다.

리얼 모드

리얼 모드는 20 비트 세그먼트 메모리 주소 공간 (정확히 1MiB의 주소 지정 가능 메모리 제공)과 모든 주소 지정 가능 메모리, I / O 주소 및 주변 장치 하드웨어에 대한 무제한의 직접 소프트웨어 액세스를 특징으로합니다. 리얼 모드는 메모리 보호, 멀티 태스킹 또는 코드 권한 수준을 지원하지 않습니다.

보호 모드

보호 가상 주소 모드라고도하는 보호 모드는 x86 호환 중앙 처리 장치 (CPU)의 작동 모드입니다. 시스템 소프트웨어는 가상 메모리, 페이징 및 안전한 멀티 태스킹과 같은 기능을 사용하여 운영 체제의 응용 프로그램 소프트웨어 제어를 향상시킵니다.

결론 : 최신 운영 체제는 보호 모드를 사용합니다. 커널 만이 실제 모드를 사용하여 하드웨어에 직접 액세스합니다. 가상 메모리를 끄려면 자체 운영 체제를 작성해야합니다.이 경우에는 CPU의 전체 전원을 사용할 수 없습니다. 이 파일이 CPU의 주소 지정 모드에 연결되어 있지 않으므로 Windows가 정상적으로 작동 할 수 있도록 페이지 파일을 다시 활성화하는 것이 좋습니다.

인텔 ® 64 및 IA-32 아키텍처 소프트웨어 개발자 설명서 결합 된 볼륨 1 및 특히 ​​"실제 주소 모드로 다시 전환"섹션을 읽으십시오 . 학교로 돌아가 친구.

지금까지 답변에 몇 가지 올바른 점이 있지만 중요한 점을 놓쳤습니다.

다른 사람들이 언급했듯이 페이지 파일을 비활성화해도 가상 메모리가 꺼지지 않습니다. 주소 변환 (페이지 테이블을 통한) 및 그로부터 얻은 모든 작업 (별도의 프로세스 주소 공간, 페이지 당 읽기 / 쓰기 및 커널 / 사용자 메모리 보호, "실행되지 않은"비트 등)은 계속 발생합니다. .

아무도 제기하지 않은 것은 페이지 파일을 비활성화해도 페이징 IO가 꺼지지 않는다는 것입니다. 페이지 파일이 없어도 디스크에서 페이징 및 페이징이 계속 발생합니다. 이것은 적어도 Windows에서는 시연하기 쉽지 않습니다. 페이지 파일을 비활성화하고, 재부팅하고, 성능 모니터 (perfmon.exe)를 시작하고, 메모리 개체 아래에서 페이징 IO 카운터를보고, 일부 프로그램을 실행하십시오.

어떻게 그렇게 될수 있니? 페이지 파일이 페이징 또는 페이징 IO에 관련된 유일한 파일이 아니기 때문에!

페이징 IO와 관련된 다른 파일은 무엇입니까? 매핑 된 파일. 그리고 "매핑 된 파일"에는 모든 코드 파일 (Windows의 경우 주로 exe 및 dll)이 포함됩니다.

프로그램 실행을 시작하거나 dll을 기존 프로세스에로드하면 코드 전체가 RAM에 복사되지 않습니다. (Windows API 이름 "LoadLibary"에도 불구하고) 코드 파일은 단순히 주소 공간에 매핑 됩니다. 판독을 수행하는 것은 호출기이며 페이지 결함에 대한 응답입니다. 페이지 결함은 명령어가 아직 페이징되지 않은 코드 페이지에서 페치 될 때 발생합니다. 즉, 코드는 가상 메모리의 다른 모든 요소와 같이 RAM으로 페이징 됩니다 (예 : 실제로 실행되지 않는 코드의 대부분은 가져 오지 않았습니다).

(여기에서 프리 페처에 대한 언급은 생략했지만 설명 된 원칙을 실제로 변경하지는 않습니다. 코드는 여전히 수요 페이징되어 있으며 프리 페처는 프로세스 수명 내에 더 빨리 발생하도록 시도합니다.)

그리고 일부 코드가 페이징되어 있고 나중에 RAM이 부족하고 새로운 페이징을위한 공간을 만들기 위해 RAM에서 이미 페이징 된 일부를 제거해야하는 경우 코드가 포함 된 페이지는 데이터 페이지처럼 페이징 될 수 있습니다 .

유일한 차이점은 코드가 포함 된 페이지는 종종 RAM에서 한 번 변경되지 않으며, 변경되지 않은 경우 다른 용도로 사용하기 전에 다른 곳에서 작성할 필요가 없다는 것입니다. 메모리 관리자에 의해 회수 된 후 나중에 다시 필요한 경우, 원래의 exe 또는 dll 파일에서 다시 페이징 될 수 있습니다.

데이터 파일, 특히 큰 파일은 종종 파일 매핑을 통해 액세스됩니다. 관련된 * nix 호출은 mmap ()이며 Windows에서는 CreateFileMapping 또는 OpenFileMapping 및 MapViewOfFile입니다. 이러한 매핑 은 종종 읽기 / 쓰기입니다. RAM에있는 동안 이러한 매핑의 페이지가 수정 된 경우 페이지를 RAM에서 제거해야 할 경우 원래 파일로 다시 기록됩니다. 페이지 파일이 관련되지 않았습니다.

쓰기시 복사 로 맵핑되지 않은 경우 . 페이지 파일이있는 경우를 제외하고는 여기에서 자세히 설명하지 않습니다.

주어진 작업량과 주어진 양의 RAM에 대해 일정한 양의 페이징이 있습니다. 페이지 파일을 끄면 일부는 매핑 된 파일이 아닌 일부는 페이지 파일이 아닌 매핑 ​​된 파일에 해당됩니다. 그러나 여전히 일어날 것입니다. 따라서 페이지 파일이없는 페이징 IO가 거의 있습니다.

따라서 페이지 파일을 끄는 것이 성능에 큰 영향을 미치지 않습니다.

실제로 상황을 악화시킬 수 있습니다. 페이지 파일이 없으면 디스크로의 페이징이 발생할 때 매핑 된 파일이 발생해야합니다. 결과 : 모든 프로세스가 수정 한 모든 비공유 페이지는 수정 된 프로세스가 종료 될 때까지 RAM에 보관해야합니다. 스택 하단에 오래된 오래된 물건을 포함하여 다시는 참조하지 않을 것입니다. 페이저는 컨텐츠를 저장할 다른 장소가 없기 때문에 (선택이 아무리 좋더라도) 제거를 위해 해당 페이지를 고려할 수 없습니다.

btw, 페이지 작성 은 일반적으로 병목 현상이별로 없습니다. 페이지 파일 또는 매핑 된 파일에 쓰는 것은 실제로 무료입니다 (앱 코드는 발생하는 동안 차단 할 필요가 없습니다. 별도의 스레드에서 실행됩니다). 실제 작업 속도를 늦추는 것은 호출기가 디스크를 읽어야 할 때, 즉 하드 페이지 오류 를 해결해야 할 때 입니다. 물론 이것은 페이지 파일과 매핑 된 파일 (코드 파일 포함) 모두에서 발생할 수 있습니다 . 결함이있는 페이지 의 백업 저장소가 무엇이든간에 .

다시 : Windows의 페이징 IO 카운터는 페이징 IO가 얼마나 발생하는지 알려줍니다. 그리고 페이지 파일이 없으면 0이 아닙니다.

주소 변환의 오버 헤드를 피하고 페이지 테이블 항목 등을 읽는 것과 관련된 OP의 질문 측면에서 오버 헤드는 매우 작습니다. 2 % 미만으로 측정되었습니다. 그 이유는 TLB (Translation Buffer) 캐시가 예상대로 작동하기 때문입니다.