불가능은 아니겠지만... 알고 싶은게 프로그램이 얼마나 많은 메모리를 사용하는 것이라면 프로그램이 사용할 메모리 페이지를 접근 불가로 만들어 놓고 (실제로 커널은 프로그램에게 물리 메모리를 할당하지 않기 때문에 처음 상태는 접근 불가입니다) 프로그램이 접근할 때마다 page fault를 일으키게 해서 얼마나 이것이 발생하는지 감시할 수 있을 것입니다. (그리고 커널은 실제로 page fault가 얼마나 발생했는지 major와 minor로 분류해서 그 횟수를 저장하고 있고 /proc 파일시스템을 통해서 이를 알 수 있습니다). 모든 메모리 접근을 저장하고 싶다면 디버거로 일일이 추적하든지 아니면 해당 아키텍처에 그런 일을 할 수 있는 debug register가 있을 수도 있고... 글쎄요..
runtime에
context switching 사이의 간격에서
process가 사용하게 되는 메모리의
size를 알고 싶었던거였습니다.
working set size가 정확한 표현이 될지 모르겠습니다만.
그것을 찾아 낼수 있는 방법과
그리고 os level에서 L2 cache hit, miss가 일어나는 횟수와
flushing되는 line의 수 정도를 알고 싶었는데,
입맛에 딱 맞는 수치를 제공하는 register가 없더라고요... (IA32 계열입니다.)
불가능은 아니겠지만... 알고 싶은게 프로그램이 얼마나 많은 메모리를 사
불가능은 아니겠지만... 알고 싶은게 프로그램이 얼마나 많은 메모리를 사용하는 것이라면 프로그램이 사용할 메모리 페이지를 접근 불가로 만들어 놓고 (실제로 커널은 프로그램에게 물리 메모리를 할당하지 않기 때문에 처음 상태는 접근 불가입니다) 프로그램이 접근할 때마다 page fault를 일으키게 해서 얼마나 이것이 발생하는지 감시할 수 있을 것입니다. (그리고 커널은 실제로 page fault가 얼마나 발생했는지 major와 minor로 분류해서 그 횟수를 저장하고 있고 /proc 파일시스템을 통해서 이를 알 수 있습니다). 모든 메모리 접근을 저장하고 싶다면 디버거로 일일이 추적하든지 아니면 해당 아키텍처에 그런 일을 할 수 있는 debug register가 있을 수도 있고... 글쎄요..
사용하려는 메모리의 주소를 알지 못한다면 메모리 디버거가 등장하지도 못했
사용하려는 메모리의 주소를 알지 못한다면 메모리 디버거가 등장하지도 못했겠지요. 필요한 것이 한 프로세스의 가상메모리 주소가 아니라 physical 한 수준이라면 또 이야기가 달라지겠지만..
전자의 경우라면 간단한 메모리 디버거를 하나 분석해보시는 것이 어떨까요. 메모리를 사용할만한 함수들을 전부 구현해서 LD_PRELOAD 시키는 방법이 대부분인 것 같습니다만...
답변 감사합니다. 두분의 말씀이 도움이 되었습니다.일단은 제가
답변 감사합니다.
두분의 말씀이 도움이 되었습니다.
일단은 제가 질문을 잘못한거 같구요.
runtime에
context switching 사이의 간격에서
process가 사용하게 되는 메모리의
size를 알고 싶었던거였습니다.
working set size가 정확한 표현이 될지 모르겠습니다만.
그것을 찾아 낼수 있는 방법과
그리고 os level에서 L2 cache hit, miss가 일어나는 횟수와
flushing되는 line의 수 정도를 알고 싶었는데,
입맛에 딱 맞는 수치를 제공하는 register가 없더라고요... (IA32 계열입니다.)
이건 어떻게 해결할수 없을까요?
댓글 달기