/proc/iomem내 컴퓨터의 비디오 카드와 같은 PCI 장치에 매핑된 중요한 주소 공간을 나타냅니다. e0000000-efffffff : 0000:01:00.0내 계산이 정확하다면 250MB입니다. RAM이 16GB에 불과한 64비트 데스크탑에서 Linux 또는 모든 최신 커널이 몇 가지 트릭을 사용하여 물리적 메모리의 이 부분을 복구할 수 있다고 가정합니다. 하지만 정확히 어떻게 될까요?
다소 관련된 질문 - 노스브리지/메모리 컨트롤러가 프로그래밍 가능한 규칙에 따라 메모리/IO 액세스를 라우팅하여 메모리 매핑된 영역(예: pci 장치)에 대한 쓰기 액세스의 경우 RAM은 이러한 쓰기에 대해 알지도 못합니다. 라우팅이 사라졌으니 일종의 "라우팅 테이블"이 있어야 할까요? 그런 테이블은 어디에 있습니까? Linux 커널은 이 테이블에 어떻게 액세스합니까?
답변1
답변2
64비트 운영 체제를 사용하고 있으므로 BIOS 설정 "4G 이상 디코딩", "64비트 I/O 주소 디코딩" 또는 시스템/마더보드 공급업체에서 부르는 모든 항목을 활성화할 수 있습니다. 이 설정이 활성화되면 64비트 주소를 처리할 수 있는 모든 MMIO 하드웨어가 기존 32비트 범위 외부의 주소에 매핑되어 메모리 충돌을 최소화하고 슬롯을 다시 매핑할 필요성을 줄입니다.
내 시스템에서 결과 GPU 맵은 다음과 같습니다.
6000000000-600fffffff : 0000:01:00.0
게다가 250MB는 16GB의 약 1.5%에 불과합니다. 마지막 1.5%의 메모리를 확보하는 것이 정말로 중요한 경우, 가능하다면 더 많은 RAM을 확보하면 상당한 성능 이점을 얻을 수 있습니다. 그냥 말인데...
내가 아는 한, 메모리 재매핑에 사용되는 "라우팅 테이블"은 적어도 부분적으로 칩셋 하드웨어에 구현되고 칩셋별로 다르므로 일반적으로 부팅 시 시스템 펌웨어에 의해 설정됩니다. 런타임 액세스가 있는 경우 ACPI 펌웨어 루틴을 통해 액세스하고 싶습니다. 그렇지 않으면 커널이 각 칩셋에 대해 특정 루틴을 제공해야 합니다.
(예, 커널에는 알려진 하드웨어 버그를 해결하기 위한 이상한 하드웨어 모델별 루틴이 있습니다. 하지만 그보다 더 깊이 들어가 시스템 펌웨어에서 제공하는 ACPI 추상화를 우회하려면 더 많은 노력이 필요합니다.핵심 지침.)