이 질문은 관련이 이것 : 나는 기능의 모든 새로 생성 된 페이지 테이블에 스와 퍼 페이지 테이블의 내용을 복사하여 사용자의 토지와 커널 땅 사이를 전환 할 때 리눅스 커널 TTBR를 업데이트 피하기 위해 시도하는 것을 발견 While "fork"ing a process, why does Linux kernel copy the content of kernel page table for every newly created process?ARM TTBR (테이블베이스 레지스터 번역) 업데이트의 단점은 무엇입니까?
pgd_alloc. 질문 : ARM TTBR을 업데이트 할 때의 단점은 무엇입니까?
TTBR (변환 테이블 기준 레지스터) 업데이트 주 1 MMU 인 에이블은 많은 위험이 있습니다. 인터럽트, 페이지 폴트, TLB (MMU- 캐시) 및 고려 될 L1 및 L2 캐시가 있습니다. 다른 시스템 인 the caches maybe PIPT or VIVT (물리적 또는 가상으로 태그가 있음)에는 L1 또는 L2 캐시가 있거나 없을 수 있습니다.
사람들은 효율성을 위해 MMU와 TLB에 지나치게 염려하고 있습니다. 이들은 성능 측면에서 항상 기본 L1/L2 캐시에 비하면 정말 왜소합니다. L1/L2 코드 및 데이터 캐시에서 불필요한 제거를하는 것보다 MMU 테이블을 업데이트하고 TLB 플러시를 수행하는 것이 더 적은 영향입니다. 최소한 TLB는 4KB 또는 100 개 이상의 캐시 라인이 필요합니다. 경우에 따라 TLB 항목이 1MB 일 수 있습니다.
L1/L2 사용자 공간의 일부 데이터/코드는 컨텍스트 스위치에서 제거해야 할 수 있습니다. 그러나 매우 작은 작업 부하의 경우 사용자 컨텍스트 스위치는 코드 및 데이터를 L1/L2에 보관할 수 있습니다. 예를 들어, 대규모 CPU 집중적 인 디코딩을 수행하는 미디어 플레이어와 새 전자 메일이 표시되지 않는 cron 작업 검사가 서버에 있습니다. 'cron'작업으로 전환하면 비디오 디코딩을 위해 코드가 L2 캐시에 남을 수 있습니다.
ARM TTBR을 업데이트 할 때의 단점은 무엇입니까?
시작/끝 테이블이 동일하지 않으면 업데이트 기간 동안 시스템보기의 메모리 일관성을 유지해야합니다. 참고 2 많은 서브 시스템을 동기화해야 할 때 자연스럽게 IRQ 대기 시간과 구현이 복잡해집니다. 또한 Linux MM (메모리 관리) 코드는 아키텍처에 무관심합니다. 그것은 다양한 MMU 서브 시스템을 처리합니다. 목표는 로컬 (아키텍처 수준에서)을 최적화하는 것이 아니라 일반 레이어에서 전역 적으로 최적화하는 것입니다.
주 1 TTBR은 ARM MMU의 첫 번째 레벨 인 물리적 인 16k 정렬 메모리 영역에 대한 포인터입니다. 각 항목은 1MB (32 비트 시스템에서)이며 다른 테이블을 가리킬 수 있습니다. 종종 L2라고 불린다.
주 2 : 부트 로더 또는 메모리 레벨간에 시스템 레벨 코드를 마이그레이션하려는 장소에서이 작업을 수행 할 수 있습니다. 즉, 동일한 테이블로 TTBR을 업데이트하는 것은 아무런 결과가 없습니다. 테이블이 달라서 이상한 일이 일어날 때입니다.
ASID (armv6 +) 및 * pid * (armv5)와 같은 ARM 기능은 플러시 할 필요성을 완화하는 데 도움이됩니다. 그러나 최악의 경우는 견고한 코드가 여전히 처리해야합니다. Linux ARM mm 코드조차도 여러 가지 ARM 변종을 처리하기위한 많은 조건부 및/또는 대체 기능이 있습니다. –