[DevLog][PintOS] 3주간의 핀토스 회고

진심 너무 힘들었다. 그래도 초반엔 재밌었는데 😇

3주간의 핀토스에서 무엇을 느끼고 배웠는지 남겨두지 않으면 나중에 '아.. 핀토스 하긴 했는데..'가 되지 않을까 싶어 정리해둔다.

1. '프로세스는 컴퓨터를 추상화한다' 라는 관점을 얻었다. 그 전까지는 프로세스, 가상메모리, 자원.. 과 같은 용어들이 막연하게만 다가왔는데, 하나의 컴퓨터를 추상화한 개념으로서 프로세스를 이해하게 된 것 같다. 자원 resource 을 공유하고, 획득하고, 반환하는 것의 구체적인 예시를 접해볼 수 있었다. 추상화이므로, 실제 물리적 자원 (ex. CPU 점유) 을 공유하면서도 마치 혼자만 쓰는 것처럼 제공해야 한다. 이런 점에서 동기화와 관련된 문제들이 중요해지는 것 같다.

2. Policy와 Mechanism을 구분해야 한다. 이를테면, 메모리가 고갈되었을 때 있는 프레임 중에서 하나를 evict한다는 것은 메커니즘이다. 어떤 프레임을 고르느냐는 정책이다. 두 가지를 분리해야 하나가 변경되어도 다른 것이 영향을 받지 않을 수 있다. 이를 구현하기 위해서는 mechanism 구현 함수 안에서 policy 함수를 콜 할 수 있도록 구현하는 것이 좋다. vm_evict_frame 안에서 vm_get_victim을 부르는 것이 대표적이다.

3. 모든 경우에 이상적인 단 하나의 방법은 있기 힘들다. 이번에 페이지 교체 정책을 실험하며 많이 느꼈던 부분이다. 이상적이라면 LRU겠지만, 이를 구현하기 위한 오버헤드가 상당하다. 주기적으로 페이지의 접근 비트를 확인해 timestamp를 남겨야 한다. LRU보다 훨씬 단순하지만 구현 복잡도를 줄인 Clock 알고리즘은 LRU의 성능을 근사한다. 하지만 Clock 역시 특정 시나리오에서는 FIFO에 비해 오버헤드로 작용할 수도 있다. 지금 이 케이스에 필요한 것이 무엇인지, 만약 메모리와 속도가 trade-off 관계라면, 영향을 받는 대상의 수가 어느 정도의 scale인지 생각해 보는 것이 좋다. copy-on-write를 위해 코드를 짜면서 구현했던 swap table의 경우, 단방향으로 구현하여 양방향보다 메모리는 덜 들었지만, 대신 remove 연산에서 O(1)이 아닌 O(n)의 시간복잡도를 갖는다. 그럼에도 이 방법을 택한 이유는.. n이 하나의 프레임을 공유하고 있는 페이지의 수이기 때문에 그렇게 많을까? 하는 생각이 들었기 때문이다. 생각만 하고 실제로 그러한지는 찾아보지 못했지만.. 다음부터는 검증도 해 보자.

4. 코드를 꼼꼼히 읽자. 개인적으로는 알고리즘 주차부터, '구체에서 추상으로'의 노선을 가지고 이해하려고 노력했던 사람으로서 이번 핀토스 주차에도 역시 코드를 보는 것이 가장 수월한 방법이었던 것 같다. 운영체제 책이나 (OSTEP은 도움이 많이 되었다) 위키피디아를 참고해서 개념을 알고 코드를 보아도 괜찮았을 것 같지만. 결국 무언가를 이해하는 순간은 개념적으로 알게 된 내용을 실제 코드에서 확인할 때였던 것 같다. context switching에 대해 대학 운영체제 강의에서 들을 때는 무슨 말인지? 별로 와닿지 않았는데, 핀토스의 thread_launch 코드가 그것의 구체적인 의미를 알려주었다.. 레지스터 상태를 어딘가(핀토스에서는 스레드 구조체)에 백업하고 다시 가져오는 과정을 확인할 수 있었다. 뭐가 되었든 작동하는 코드보다 디테일한 자료는 없다는 생각으로 꼼꼼히 읽어보고 이해하는 시간을 들이자.

5. 왜 되는지를 생각해보자. 핀토스는 이미 작동하는 운영체제를 더욱 발전시키는 프로젝트이므로, 내가 짜 준 게 없어도 어딘가에서 코드가 돌아가고 있다. 사실 코드를 짜는 시간만큼, 코드를 읽고 이해하는 시간도 많이 들었던 것 같다. 코드량이 많다보니 1주차 때는 '왜 되지?' 에 대한 고민보다는 그저 어딘가에서 처리해주고 있겠거니, 하는 마인드가 살짝 있었던 것 같다. 하지만 컴퓨터에 마법은 없으므로.. 하나의 흐름, 이를테면 인터럽트의 발생부터 종료까지의 흐름을 찬찬히 추적해 보면서 실제 코드가 어떻게 처리되는지를 짚어보는 것이 도움이 되었다. intr-stub.S 에서 intr_handler의 인자로 들어가는 intr_frame* 값이 어떻게 전달되는지를 몰라서 (CSAPP 8장을 안 읽어서 🙃) 궁금증을 가지고 있었는데, %rdi 레지스터를 함수 호출 전 인자를 전달하는 데 사용한다는 것을 GPT를 통해 알게 되었다. 이런 식으로 궁금증을 해결해 나가면서 인터럽트 흐름을 살펴 본 경험이 2주차 syscall에서도 많이 도움 되었던 것 같다. 사소한 의문도.. 모두 GPT에게 물어보면 잘 답변해준다. 98년도에 핀토스를 하던 대학생들에 비하면 어마어마한 혜택이므로 잘 사용한자.

6. 안전한 코드를 고려해보자. 2주차에 밤샘하며 해결했던 multi-oom 테스트 (메모리 누수가 있는지를 확인하는 테스트) 이후 모든 alloc 관련 함수는 강박적으로 free해줄 곳 없나.. 체크하면서 코드를 짜려고 노력하고 있다. 그런데 이게 생각보다 매우 쉽지 않은 작업인 것 같다. 이번에 프로젝트 3에서 동기화 문제(데드락)를 많이 겪었는데, 이를테면 system call의 파일 관련 함수에서 락을 획득하고 난 후 fault가 발생하고 lazy_load로 가서.. 다시 load 관련 락을 획득하는 과정 중에서 뭔가 꼬이는 경우가 생겼던 것 같다. 항상 함수가 리턴되거나, 사실 더욱 중요하게는 예기치 않게 종료되는 경우를 고려해야 한다. 그리고 만약 종료되는 케이스 안에서 자원 반환이라던지.. 를 해결해주지 못한다면, 그 케이스 밖으로 반환 또는 정리 로직을 빼는 것도 방법일 수 있겠다. spt_table_kill에서 hash_destroy를 하며 file writeback을 하는것보다, 한차례 writeback을 한 뒤 마음 편하게 destroy로 free시켜주는 것이 나았다. 의도하는 동작들을 잘 나누어서 함수로 만들면 좋다.

7. ASSERT 문을 적극 활용하자. 핀토스에서 semaphore와는 달리 lock은 현재 스레드가 lock을 잡았는데 다시 획득하려고 한다면 ASSERT를 발생시킴으로서 에러를 확인시켜준다. 따라서 데드락이 발생한 지점을 쉽게 파악할 수 있고, 수정할 수 있다. 코치님께서 'ASSERT는 디버깅 과정을 컴퓨터에게 시키는 것'이라고 말씀하셨던 의미가 이번 프로젝트 (특히 Virtual Memory)를 하면서 와닿았던 것 같다. 페이지의 상태에 따라 처리 로직이 달라지다보니, 이 함수에 진입했을 때 의도한 페이지의 상태는 어때야 한다 - 라는 조건들이 있었다. if문으로 예외처리 할 수도 있겠지만, 만약 의도한 대로 코드가 돌아가야 한다는 확신이 있다면 ASSERT를 심어서 내 생각을 검증해 볼 수 있다. 이런 식으로 삐끗한 부분을 확인하고, 이어붙이고.. 의 과정을 거치면서 디버깅했던 것 같다. 무작정 돌리고 gdb로 찾는 것보다 훨씬 낫다.

이 밖에도 핀토스를 하면서 많은 것을 얻었다. 일단 이 정도 양의 코드를 언제 읽어보겠으며.. 수정해보겠으며.. 그것만으로도 부담감이 있는 프로젝트였던 것은 확실하다. 태도적으로 느낀 점이 있다면: 모르겠으면 물어보고, 검색하고, GPT 적극 활용하고, 아무튼간에 작은 의문도 해소하려는 자세가 중요한 것 같다. 그리고 코드와 구현에 풀로 집중하는 태도가 있어야 간신히 과제를 (all pass가 아니더라도) 끝낼 수 있는.. 양인 것 같다. 과제에서 얻어갈 수 있는 것의 100%는 고사하고 80%라도 잘 배워가는지에 대한 의문은 있지만, 이런 경험을 해 본 적 있다는 것만으로도 앞으로 프로젝트를 해나가는데 있어 큰 도움이 되지 않을까.. 싶다. 힘들고 벅차고 그래도 조금은 재미있었던 핀토스 회고 끝 🍀