이번 주는 핀토스의 마지막 주차인 파일 시스템이다. 보통 핀토스는 프로젝트 2와 3이 가장 어려운 편이고, 마지막 프로젝트 4가 쉬운 편이라고 하는데 그렇다고 만만할 정도는 아니었다... 그래도 핀토스에 대한 흐름이 어느 정도 잡혀있어서 그런지 초반에 개념을 잡고 나니 구현은 생각보다 빠르게 진행됐다. 초반에 개념 잡는 게 어려우니 오늘 포스팅은 파일 시스템의 기본 개념에 대해서 다뤄보려고 한다! Inode 먼저 핀토스가 제공하는 기본 코드에 대해서 살펴보자. 커널에서 파일이나 directory에 접근할 때 항상 inode라는 구조체를 거쳐서 접근하게 된다. inode 구조체를 살펴보자! /* In-memory inode. */ struct inode { struct list_elem elem;/* El..
이번 포스팅에서는 개념에 관한 정리보다는 프로젝트를 진행하면서 궁금했던 점을 위주로 정리해보려고 한다! 프로젝트 3을 진행하다 보면, anon page나 file page에서 swap in 함수로 load_segment 함수를 사용할 일이 생긴다. 이때 load를 할 주소 값을 user virtual address로 넘겨주는 경우와 kernel virtual address로 넘겨주는 경우의 차이가 발생한다. 이 차이가 왜 발생하는지, 또 user virtual address의 경우 kernel virtual address와의 mapping 정보를 page table에 추가해 주었기 때문에 참조가 가능한데, kernel virtual address는 어떻게 바로 참조가 가능한지에 대해 알아보았다. User..
드디어 대망의 프로세스 관련 시스템 콜이다..! 앞에서 소개했던 파일 입출력 관련 시스템 콜은 거의 래핑 함수 위주여서 구현이 어렵지는 않았던 반면, 프로세스 관련 시스템 콜들은 구현할 양도 앞의 포스팅에 비해 많은 편이고 무엇보다도 개념 자체가 쉽게 와닿지 않아 많이 어려웠다고 느꼈다. 프로세스와 관련된 시스템 콜은 fork, exit, exec, wait 으로 총 네 가지가 있다. 이 파트가 특히 어려웠던 점은, 네 개의 시스템 콜 중 하나라도 제대로 구현이 되어있지 않으면 거의 모든 프로세스 시스템 콜 테스트가 통과되지 않아 네 개를 모두 구현하고 나서야 결과를 확인할 수 있었다는 점이다. 구현할 양도 꽤나 많은 편이라 네 개를 모두 구현하고 나서 문제가 생기면 그 문제를 찾기가 꽤나 힘들어진다....
이번 주는 가상 메모리와 관련된 과제를 진행하였다. VM 파트는 크게 Memory Management, Anonymous Page, Stack Growth, Memory Mapped Files, Swap in/out으로 구분되며 extra로 Copy-on-Write까지 있다. 이번 포스팅에서는 위의 내용들 중에서 Memory Management 파트에 대해 다뤄볼 예정이다. User Pool & Kernel Pool 사실 memory management 파트에서는 구현할 부분이 다른 파트에 비해 많지는 않은 편이다. 다만 초반에 코드의 흐름을 잡기가 힘들고, 가상 메모리 개념 자체가 잘 와닿지 않기때문에 핀토스의 메모리 구조와 프레임 할당 방식에 관해 중점적으로 다뤄볼 것이다. 우선 핀토스는 아래 그림과..
핀토스 프로젝트 2의 시작은 시스템 콜부터다. 사실상 argument passing은 몸풀기... 문제는 몸풀기 수준이었던 argument passing조차도 쉽지만은 않았다는 거..! 이번 포스팅에서는 시스템 콜 중에서 파일 입출력과 관련된 시스템 콜들을 다뤄볼 예정이다. 저번에 웹 프록시 서버를 구현할 때 소켓을 파일로 추상화하여 소켓에게도 파일 디스크립터가 붙었는데, 이번에도 파일 디스크립터 개념을 사용한다. 파일 디스크립터와 관련해서는 다뤘던 포스팅이 있으니 참고하자. https://codable.tistory.com/19 [Computer System] File Descriptor File Descriptor 유닉스 시스템에서는 많은 것들을 파일로 관리한다. 정규 파일들뿐만 아니라 디렉터리, 소..
핀토스 프로젝트 1의 extra 과제이다. multi-level feedback queue scheduler의 구현인데, 일단 저번 포스팅에서 소개했던 스케줄러들과 비교해서 어떤 점이 좋은지 살펴보자. 기존 Priority Scheduler의 문제점 기존 우선순위 스케줄러는 저번 포스팅에서도 언급했다시피 우선순위가 낮은 작업이 계속해서 순서가 밀려 CPU를 얻지 못하는 Starvation 현상이 발생할 수 있다는 점이 있었다. 물론 핀토스에서 구현하는 우선순위 스케줄러에서는 priority donation도 있어 우선순위가 낮은 작업도 충분히 실행될 기회를 잡을 수 있지만, 특별히 락을 소유하지 않고 우선순위도 낮은 작업들은 이러한 조정도 받지 못할 수 있다. 이로 인해 task들의 평균 대기 시간이 길..
핀토스 프로젝트 2는 유저 프로그램에 관한 과제다. 첫 번째 프로젝트는 모두 커널 영역에서 진행이 되었다.(이거 덕분에 나름 디버깅이 편했던 편...) 두 번째 프로젝트는 크게 두 가지 파트로 나뉘는데, 이번 포스팅에서는 그 첫 번째를 다뤄보고자 한다. Argument Passing 첫번째로 argument passing이다. 우리가 함수를 사용할 때, 함수에 인자를 넘겨주는 방식을 구현하는 과제다! 우리가 인자를 함수로 넘겨줄 때 스택에 넣어두었다가 함수에 진입하고 나면 스택에서 argument를 꺼내 사용한다. 예를 들어 다음과 같은 코드가 있다고 생각해보자. void add(int a, int b) { printf("%d\n", a + b); } 위의 add 함수는 인자로 a와 b를 넘겨받고, 각각..
핀토스 프로젝트를 하면서 크게 두 가지 스케줄러를 구현해보았다. 물론 기본적으로 구현되어있는 busy waiting 또한 스케줄링 방식 중 하나이지만 내가 구현한 것이 아니니까.. 이번 포스팅에서는 CPU 스케줄러에 대해서 조금 더 자세히 알아보고자 한다. CPU Scheduling Criteria 먼저 스케줄러의 성능 척도에 대해서 알아보고 가자. 크게 다섯 가지가 있는데 다음과 같다. 1. CPU Utilization(프로세서 이용률) CPU를 사용한 시간의 비율을 나타낸다. CPU가 오랜 시간동안 바쁜 상태로 있을 때 높아진다. 대기 시간이 긴 I/O 작업이 많을수록 나빠지며, 단순 연산 작업만 많은 경우 높아진다. 2. Throughput(처리율) 시간당 처리한 작업의 비율을 의미한다. mallo..
드디어 대망의 핀토스다..! 프로젝트 1은 스레드에 관한 내용이다. 좀 더 정확히 짚어서 말하자면 스케줄링 알고리즘 구현이라고 볼 수 있겠다. CPU Scheduling 우리가 사용하는 컴퓨터에서는 여러 개의 프로그램들이 동시에 돌아가고 있다. 좀 더 엄밀히 말하면 동시에 돌아가는 것처럼 보이는 것이다. 사실은 한개의 프로그램만이 하나의 CPU 코어를 사용할 수 있고, 사용 주기가 굉장히 빠르게 교체되기 때문에 우리 눈에는 프로그램들이 동시에 돌아가는 것처럼 보이는 것이다. 여기까지는 우리가 컴퓨터를 보는 입장에서의 설명이었고, 프로그램의 입장에서는 CPU를 마치 자기 자신만이 소유한 것처럼 사용할 수 있게 하는 것이 CPU Scheduling의 목표이다. 현재 프로그램이 디스크에 접근하거나, 키보드의 ..
