풀캠정글러

이번주는 핀토스의 마지막 프로젝트인 file system을 진행했다. project 3을 거하게 말아먹어서, 프로젝트 1, 2, 3의 개념적 구멍을 메우는데 쓴 시간 + 나만의 무기 준비에 훨씬 더 많은 시간을 써서 많은 걸 하진 못했다. 그럼에도 '파일 시스템'이라는 개념이 십수년간 컴퓨터를 쓰면서 계속 접해온 것이다 보니 제일 직관적으로 와닿는 개념들이 아니었나 싶다. '파일'이란 연속된 메모리의 기록 속에서 의미를 가지는 단위를 의미하며 고유한 inode를 가지는 것 HDD는 말 그대로 '디스크'의 집단이라 각 섹터는 이 원판집단에서의 물리적 위치와 대응되는 것 디스크 포맷할때 보던 FAT는 메모리를 단위크기의 클러스터로 분할해 링크드 리스트화한 것 마운트는 보조기억장치를 마운트 위치에 해당하는 디..

이번 프로젝트는 지금까지의 정글 커리큘럼 중 가장 길고 가장 어려웠다. 가장 어려웠기 때문에 2주라는 긴 시간이 주어졌지만 그마저도 독이 되었던 것 같다. 2주일이 주어진 나는 과연 1주일이 주어진 나보다 많은 일을 했는가 생각을 해보면 그렇다고 답하기가 힘들다. 많은 일이 있었는데, 프로젝트와 관계없이 모두가 겪은 일도 있었지만 그보다도 내게 치명적으로 작용한건 개발 실패(?)였다. 이번 프로젝트 중 도저히 에러의 원인을 알 수가 없어서 다 갈아엎고 프로젝트 2의 종료점부터 다시 시작하길 두번이나 했고, 심지어 두번째 리셋은 지난 토요일이었다. 이런 삽질의 반복을 경험하며 그동안의 공부방식을 다시한번 되돌아보게 되었다. 알고리즘부터 핀토스 전반부까지, 나는 목적과 목표를 정해두고 필요한 만큼 배우는 방..

이번주에도 과제의 구현에 집중하면서 필요한 깊이만큼 이론을 배워나가며 진행했다. 커맨드라인 파싱은 할만했다고 생각한다. 어디에서 무엇을 해야 할지를 제시해주었기 때문에, 이 기능이 왜 필요하고 어떤 방식으로 구현해야 하는지에 초점을 맞추면 결국 남는 것은 '잘 구현하는 것' 뿐이어서 시키는 대로 잘 구혔했다. 그런데 'Implement user memory access' 부터 무언가 잘못되었음을 느꼈다. 분명 VM은 프로젝트 3의 영역이라고 믿고 있었는데 이렇게 발을 걸치니 VM 관련 공부를 하고 와야하나, 아니면 그냥 함수 따라 올라가며 대강 어떻게 작동하는지말 알고 넘어가야 하나부터 고민이 많았다. 결국 이후 구현할 수많은 시스템콜의 구현량이 두려워 후자를 택하고, '커널 영역을 유저 영역 뒤(더 큰..

각 파트의 문제점과 그것을 개선하기 위한 구현 방향을 정리해보았다. 각 파트를 어떻게 구현했는지는 따로 포스트로 정리하고 있다. https://uneducatedjungler.tistory.com/141 [KAIST PintOS Project 1] 1. sleep and awake KAIST 핀토스를 기반으로 만든 코드는 재배포가 불가능하다고 프로젝트 가이드라인의 legal issue에 명시되어있다. 라이센스를 찾아봤는데 프로젝트에 따라 자기가 작성한 부분도 배포가 불가능하 uneducatedjungler.tistory.com https://uneducatedjungler.tistory.com/142 [KAIST PintOS Project 1] 2. priority scheduling priority s..

synchronization 지난 단계에서는 선입선출의 queue 구조였던 ready_list를 스레드의 priority에 따르는 heap 구조로 바꾸어 보다 효율적인 스케줄링을 하도록 개선했다. 그런데 이와 같은 아이디어로 똑같은 개선이 가능한 list가 둘 더 있다. 바로 세마포어의 waiters와 컨디션의 waiters이다. semaphore.waiters는 semaphore를 갖기 위해 대기중인 스레드를 elem으로 갖는 list이고, cond.waiters는 condition을 갖기 위해 대기중인 semaphore의 list인데, 둘 모두 개선 전의 ready_list처럼 선입선출의 구조를 갖고 있다. ready_list때와 마찬가지로 이는 우선도가 높은 스레드가 낮은 스레드를 기다리는 문제를 ..

priority scheduling 지난 단계에서는 CPU를 정말로 쓸 스레드만 ready_list에 삽입하는 sleep & awake의 구현으로 불필요한 토스를 줄여 기능을 개선했다. 이번 단계의 목표는 수많은 ready 상태의 대기중인 스레드 중 우선도가 높은 순서대로 사용하도록 하는 기능의 구현이다. 간단히 말해 ready_list를 queue에서 priority에 따르는 heap으로 바꾸는 것이 목적이다. 순서 1 ~ 2 스레드간의 우선도를 따지기 위해 각 스레드마다 priority라는 값을 가진다. 기존에 선착순으로 ready_list에 진입하던 구조를 개선하여 이 priority에 따라 ready_list가 정렬되도록 한다면, 항상 ready_list의 first만 취하는 현재의 알고리즘대로 ..

KAIST 핀토스를 기반으로 만든 코드는 재배포가 불가능하다고 프로젝트 가이드라인의 legal issue에 명시되어있다. 라이센스를 찾아봤는데 프로젝트에 따라 자기가 작성한 부분도 배포가 불가능하다고 한다. 따라서 코드는 블로그에 첨부하지 않는다. 이걸 코드없이 정리하려니 답이 없어서 내가 구현을 진행한 부분들을 순서대로 기록해봤다. sleep and awake 기존 timer는 busy waits이 발생하는 구조를 갖고 있었다. 알람 시각에 도달하기를 그저 기다리는 스레드들이 계속 서로에게 CPU 사용 권한을 넘겨주고, 알람 시각이 아니라면 다시 다른 스레드에게 CPU 사용 권한을 넘기는, 이러한 무의미한 토스를 반복하며 CPU의 사용 권한이라는 공유자원에 낭비가 일어나는 것이다. 각 스레드들이 기상시..