투명 대형 페이지 (THP)가 큰 페이지 폴트 지연을 일으키고 있는지 확인하고 싶습니다. 리눅스는 페이지를 사용자에게 보내기 전에 제로 페이지를 가져야하기 때문입니다. THP는 4KB 페이지보다 512 배 크므로 삭제가 느립니다. 메모리가 단편화되면 OS는 종종 메모리를 압축하여 THP를 생성합니다.부 페이지 오류 비용을 측정하는 방법은 무엇입니까?
그래서 마이너 페이지 폴트 레이턴시 (비용)를 측정하고 싶지만 여전히 잘 모른다.
https://www.kernel.org/doc/Documentation/vm/transhuge.txt을 확인하고 LHN & THH 대기 시간 및 THP 오류에 대한 RedHat 문서를 검색하십시오.
https://www.kernel.org/doc/Documentation/vm/transhuge.txt 제로 THP에 대해 말한다 : 기본 커널에 의해
이 익명 매핑 읽기 페이지 오류에 큰 영 페이지를 사용하려고합니다. 그것은 1을 써서 0 를 작성하여 거대한 제로 페이지를 비활성화하거나 다시 활성화 가능 :
echo 0 >/sys/kernel/mm/transparent_hugepage/use_zero_page echo 1 >/sys/kernel/mm/transparent_hugepage/use_zero_page
당신은 (2012 주위 소개 : 거대한 제로 페이지를 추가 https://lwn.net/Articles/517465/) 설정을 변경할 수 있으며, 페이지의 측정을 매핑 및 액세스 대기 시간. rdtsc/rdtscp/CLOCK_MONOTONIC을 사용하여 시스템 시간을 읽으십시오. 다시 읽는 시간입니다. 최소/최대/평균과 같은 시차에 대한 통계를 기록합니다. 히스토그램 그리기 - 0..100, 101..300, 301..600 ... 범위에 몇 가지 차이가 있었는지와 몇 가지 큰 값보다 몇 가지 큰 차이가 있는지 계산합니다. 히스토그램을 카운트하는 어레이는 충분히 작아야합니다.
당신은 MAP_POPULATE 플래그의 mmap()을 시도 할 수 있습니다 - (http://d3s.mff.cuni.cz/teaching/advanced_operating_systems/slides/10_huge_pages.pdf 17 페이지)
레드햇 블로그 (자신의 STAP의 SystemTap의 추적의 도움으로) THP & 페이지 오류 대기 시간에 대해 게시했습니다 https://developers.redhat.com/blog/2014/03/10/examining-huge-pages-or-transparent-huge-pages-performance/
이전 페이지 사용자의 정보 유출을 막기 위해 커널은 전체 페이지에 0을 씁니다. 4096 바이트 페이지의 경우 이것은 상대적으로 짧은 조작이며 불과 몇 마이크로 초가 소요됩니다. x86 거대한 페이지 크기는 2MB이며 일반 페이지보다 512 배 더 큽니다. 따라서 작업에는 수백 마이크로 초가 소요될 수 있으며 대기 시간에 민감한 코드의 작동에 영향을 미칠 수 있습니다. 아래는 간단한 SystemTap 명령 줄 스크립트로, 거대한 페이지가없는 응용 프로그램과 그 작업이 얼마나 오래 걸리는지를 보여줍니다. cntl-c를 누를 때까지 실행됩니다.
stap -e 'global huge_clear probe kernel.function("clear_huge_page").return { huge_clear [execname(), pid()] <<< (gettimeofday_us() - @entry(gettimeofday_us()))}'
또한, 나는 이것에 대해 잘 모르겠지만, 이론적으로, 리눅스 커널은 어떤 응용 프로그램에 필요한되기 전에 큰 페이지의 prezeroing을 할 수있는 몇 가지 커널 스레드가있을 수 있습니다.