4/1 (월) 오늘의 TIL - Stack glowth 성공

 

 

 

오늘은 스택 글로우에 대한 테스트케이스를 모두 성공하고, mmap, munmap 구현을 시작했다.

 

 

! 오늘의 속상한 점

 

palloc을 포기했다... page-linear 등 페이지와 관련된 테스트 케이스는 굉장히 큰 크기의 페이지를 할당받으려 하는데,

우리는 palloc을 사용하면서 하나의 페이지만 처음에 할당하기 때문에 케이스를 통과하지 못했다.

malloc의 경우 2MB 정도의 큰 크기로 메모리를 할당하기 때문에 malloc을 써서 통과할 수 있었다.

 

물론 페이지의 크기를 PGSIZE로 나눈 값만큼 palloc_get_multiple(size) 해주면 가능할 것 같다!

그런데 굳이 계산을 더 추가할만큼 palloc의 메리트가 있냐하면 그렇지는 않아서...더 간단하게 malloc을 사용했다..아쉽다

케이스를 모두 통과하게 되면 palloc을 이용해서 구현해봐야겠다.

 

 

! 오늘의 트러블 슈팅

 

테스트 케이스 중에 파일에 대한 read, write 등을 정적 변수를 이용하는 케이스가 있었다.정적 변수는 동적 할당을 하지 않았기 때문에 페이지 테이블 등에 존재하지 않았고, spt 테이블에서 찾으려고 하니 계속 NULL을 반환했다.그래서 페이지가 NULL 일 때, exit(-1)을 하던 조건을 삭제하고, 우리가 사용할 버퍼에 대한 쓰기 권한을 체크하도록 추가했다. 아래 코드는 쓰기 권한에 대한 조건문이다.

if (p && !p->writable)

 

 

! 오늘의 잘한 점

 

mmap과 munmap을 구현하면서 다른 코드를 거의 참고하지 않고, 테스트 케이스를 통과했다! 모든 케이스를 통과하지는 못 했지만, 이번 Project 3을 하면서 다른 분들의 코드나 블로그를 정말 많이 참고했기 때문에 약간 기분이 좋았다. 나도 할 수 있어~라는 마음이었다 ㅋㅋ 물론 그 이후로 계속 변경되었지만 ㅜㅜ 앞으로도 최대한 스스로 구현하도록 노력하고자 한다.

 

 

! 오늘의 어려웠던 이론

 

rsp와 addr간의 상관관계

stack glowth하면서 들었던 의문이다. 왜 addr는 rsp보다 큰 주소를 가져야 하는가?

 

왜냐! 우리는 rsp를 스택의 bottom과 같다고 여기고 있고, (rsp - 8은 return addr)

스택의 범위를 넘어선 write는 다른 메모리를 건드리거나 추후 덮어쓰여질 위험이 있다고 판단해 좋지 않은 접근이라고 OS는 생각한다. 그에 맞추어 조건문을 작성했던 것이다.

 

rsp는 페이지 폴트가 발생하기 전, 스택에 무언가 데이터가 추가될 때 늘어난다. 하지만 우리는 lazy_loading을 구현했기 때문에 USER_STACK에 데이터가 PUSH되었다고 해서 물리메모리가 유효하다는 보장이 없다.

 

그래서 스택의 주소에서 페이지 폴트가 발생한건지를 판단해서 stack_glowth()를 호출한다.

stack_glowth()를 호출해야 드디어 스택 내의 데이터에 물리메모리가 맵핑되는 것이다.

 

라고 이해했다...굿

 

남은 테스트 케이스 17개! 파이팅이다...내일은 저녁먹기 전에 page 관련된 테스트케이스 통과시키고, 다음 구현 시작해야한다! swap이 남았으니까...화이팅...