! 오늘의 이슈
어디서 발생하는지 모르는 Page Fault
며칠간 열심히 구현한 결과, 많이 늦었지만 ㅠ Anonymous page 페이지 테이블 copy 직전까지 구현했다.
물론 fork() 이전에도 read-boundary, open-empty 같은 케이스가 실패한다...어딘가 예외처리를 덜 한 모양.
일단 gitbook에 써있는 가이드와 선배님이 작성해두신 sudo 코드처럼 글로만 가이드해두신 글을 보고 구현했다.
그러고 한참 안 돼서...정답 코드와 비교해보며 작성했다. 거의 우리가 작성한 코드와 같아서 대체 어디가 문제인지 고민했다.
printf()를 이용해서 디버깅을 진행했는데, 이상하다 느꼈던 부분은 spt_find_page()에서 리턴하지를 않았다는 것이다.
분명 함수를 모두 처리하고 return 직전 printf까지 진행이 되는데 함수 밖의 printf가 진행되지 않고 계속 page fault를 호출했다.
분명 page가 정상적이면 page를 반환하고, NULL이라면 NULL을 리턴해 함수가 끝나면 예외처리를 해주는 흐름이었다.
뭐가 문젠지 정답 코드와 비교하며 살펴보다가...vm_get_frame()에서 frame에 메모리 할당을 해주지 않은 걸 발견했다...아차차...
이런 작은 실수가(작지 않지만) 전혀 다른 위치에서 문제를 일으켰던 것이다.
물론 우리가 헷갈렸던 것도 있었다. 어떤 변수를 메모리 할당을 받아야 하고, 어떤 변수를 받지 않아야 하는지 구분이 헷갈렸다.
앞으로는 *로 선언해주는 변수를 활용하는 경우, 메모리 할당을 해주는걸로...
그래도 오늘은 진행이 되어서 다행이다. 원래 어제 마무리하기로 했었는데 하루가 늦어졌다. ㅜㅜ
내일부터 좀 빡세게...가보자고...
! 기분 좋았던 점
다들 malloc()을 사용하셨고(선배님, 진도가 빨랐던 다른 정글러분), 우리는 palloc_get_page()를 이용해 할당했었다. 할당하는 함수 문제인줄 알고 palloc을 다 malloc으로 바꿨었는데, 메모리 할당 문제가 해결된 뒤에 다시 palloc을 사용해본 결과 문제 없이 pass를 받았다!
우리 선택이 틀리지 않았다는 것이 기분이 좋았다 ㅎㅎ
우리가 palloc을 선택한 이유! malloc 함수 내부에서 palloc을 호출했기 때문에...palloc을 호출해도 문제 없다고 판단했다.
palloc에서는 플래그를 이용해 여러 기능을 달리 할 수 있기 때문에 palloc을 계속 사용하고 싶었다.
우리는 틀리지 않았고, 조금...멍청햇을뿐 ㅠ
내일은 NO멍청Day가 되기를
! 약간 의문이었던 점
hash_find()를 사용할 때 hash_elem을 넣어줘야 하기 때문에 spt_find_page()에서 va를 이용해 page를 찾으려면 iterator를 이용해 page->va 와 매개변수 va의 값을 비교하는 방법만 있다고 생각했다.
다른 정글러분과 위에 얘기한 블로그에서는
1. 비어있는 페이지를 메모리 할당하고
2. 페이지->va = va 설정하고
3. 해당 페이지의 hash_elem으로 hash_find()를 해서
페이지를 찾으셨다.
우리가 생각했을 때는 방금 생성한 페이지가 어떻게 hash에 삽입되어있는 hash_elem을 갖고있냐...라는 건데
흠...아직도 모르겠다. 정리해서 질문을 해보는 것도 좋겠다.
'TIL (Today I Learned)' 카테고리의 다른 글
4/1 (월) 오늘의 TIL - Stack glowth 성공 (0) | 2024.04.02 |
---|---|
3/29 (금) TIL - fork 테스트케이스까지 모두 통과! (0) | 2024.03.30 |
10주차 키워드 정리 (1) | 2024.03.26 |
3/20 (수) TIL - 오늘은 반드시 (2) | 2024.03.21 |
3/19 (화) TIL - 오늘은 꼭 fork를 끝내야지 (0) | 2024.03.19 |