나는 eMMC를 지원하는 Linux 3.10 개발 장치(Android)를 가지고 있으며 Linux가 실제로 페이지 캐시 대신 eMMC에서 읽는 경우를 더 잘 이해하려고 노력하고 있습니다. 특히 ELF 로딩 프로세스에 관심이 있는데 다음 결과를 설명할 수 없습니다.
init가 실행 중인 파일 시스템에 ELF 파일을 배치했는데 종료되지 않습니다. ELF 파일 데이터는 블록 0x22d930-0x22da78에 있으며 이 블록에 대한 모든 eMMC 읽기 액세스를 기록하도록 커널을 수정했습니다. 부팅 프로세스 중에 로그에는 eMMC에서 전체 ELF 파일을 읽었다는 내용이 표시됩니다.
mmc read block: 0x22d930, num_blocks: 0x20
mmc read block: 0x22d9f0, num_blocks: 0x88
mmc read block: 0x22d950, num_blocks: 0xa0
이는 init의 첫 번째 분기/실행이 내 ELF(0x20 + 0x88 + 0xa0 = 0x22da78 - 0x22d930)일 때 eMMC에서 전체 ELF를 읽기를 원하기 때문에 이해가 됩니다.
페이지 캐시를 삭제하고 프로세스를 종료하면 혼란스러워집니다. 프로세스를 종료하면 다른 분기/execve를 통해 프로세스를 자동으로 다시 시작하도록 init가 구성됩니다. 페이지 캐시를 삭제하면 eMMC에서 전체 ELF를 다시 읽을 수 있기를 바랍니다. 그러나 다음 명령을 실행한 후에는 부분적인 eMMC 읽기 액세스만 표시됩니다.
echo 3 > /proc/sys/vm/drop_caches && kill -9 <pid>
mmc read block: 0x22d960, num_blocks: 0x10
mmc read block: 0x22d988, num_blocks: 0x8
mmc read block: 0x22d9a0, num_blocks: 0x8
mmc read block: 0x22d9c0, num_blocks: 0x40
mmc read block: 0x22da40, num_blocks: x018
mmc read block: 0x22da60, num_blocks: 0x18
내 프로세스가 새 PID로 성공적으로 다시 시작되었지만 Linux가 디스크에서 전체 ELF를 다시 읽지 못하는 이유를 이해할 수 없습니다. Linux는 execve가 읽는 첫 번째 파일인 ELF 헤더도 다시 읽지 않습니다.
원본 프로세스의 원본 파일 맵 일부가 여전히 일부 캐시/RAM에 있습니까? 다음 명령은 내 프로세스만 보여줍니다.
lsof | grep <ELF name>
이 동작을 설명하고 논리에 문제가 있다고 생각하는 데 도움을 주시면 감사하겠습니다.
답변1
문제는 init 재시작 프로세스와 페이지 캐시 삭제 사이의 타이밍인 것 같습니다. kill -9 <pid> && echo 3 > /proc/sys/vm/drop_caches올바른 순서는 방출되는 대신 다음과 같은 것 같습니다.
stop <service>
echo 3 > /proc/sys/vm/drop_caches
start <service>
서비스가 중지되면 파일 매핑이 더 이상 페이지 캐시에 잠겨 있지 않으며 이제 삭제할 수 있습니다. 이로 인해 Linux는 서비스가 다시 시작될 때 디스크에서 ELF를 다시 읽습니다.