Project3를 정리하면서, 여태 정리했던 TIL들을 정리했다. 우선 PintOS 프로젝트 3를 진행하면서 명확하게 해야 하는 부분들을 먼저 정리하겠다. PintOS에서 어떻게 가상메모리를 관리하는지에 대해서 정리해본다. 핀토스는 가상메모리 page들을 pml4로 관리한다. pml4는 multi_level로 구성되어있는 페이지 테이블이다. - struct page 가장 나를 헷갈리게 했던 부분이, struct page이다. struct page는 페이지를 관리하기 위해서 해당 페이지에 대해서 정보를 담아놓는 구조체이다. struct frame도 마찬가지이다. 페이지 구조체의 주소값을 통해가면 실제 페이지에 디스크 데이터를 매핑되어 있다. 처음에는 struct page가 실제 페이지를 의미하는 것으로 생각했지만, 해당부분은 달랐다. 그리고 이제 새롭게 추가된 lazyloadsegment방식으로 작동하기 때문에, 이제 page에 즉각적으로 data를 mapping

프로젝트 마감일이 다 되었는데, MemoryMappedFile을 진행하면서, Thread 관련 테스트가 fail로 바뀐 것을 알았다. fail이 뜨는 테스트를 통과에만 집중하다가 보니 아래쪽에 Thread_관련 테스트 fail이 뜨는 것을 늦게 발견했다. 그래서 다시 thread 통과를 위해서 디버깅을 시작했다. Panic이 뜨는 것을 보고 도대체 어떤 지점에서 터지기 시작했는지 다시 처음부터 뒤져보았다. 디버깅의 연속으로 processcleanup() 함수에서 문제가 발생하는 것을 확인했는데, 이 함수 내부에서 VM에서부터 적용되는 sptkill()함수에서 문제가 발생했던 것이었다. 이 함수는 프로세스를 실행하면서 spttable을 init이 되어야 메모리가 할당되며 접근이 가능한데, 프로세스 실행 프로세스에 따르면 init 전에 실행하면서 hashtable에 접근하면서 Panic이 발생한 것. 그래서 if 문을 통해 선택적으로 실행하도록 수정해서 문제를 해결했

힘겹게 진행하는 3주차에서 PintOS에 치이다가 이제서야 이어서 포스팅을 올린다. 그동안 많은 변화가 있었다. 지난번에 이어졌던 문제상황도 포스팅하고 몇가지만 추가로 적어서 기록하고자 한다. 일단 지난번에 무한루프에 빠졌던 이유는, notpresent 대신에 write을 썼기 때문에 그랬다. if(write)에서 검사를 하고, 실제 페이지 할당을 위해서 vmdoclaimpage를 실행해야 하는데, notpresent 여부(페이지가 할당되어 있는지)를 확인하지 않고, write에서부터 걸러져서 문제가 발생했기 때문. faulthandler를 거치고 나서도 다시 똑같은 주소에 접근했더니, 계속 무한루프를 도는 것. 이 문제를 해결 하고 나서도 많은 문제가 있었다. 특히 유저 스택을 설정해주는 부분에서 많은 문제가 발생했는데, 이 부분이 가장 어려웠다. 가장 오랫동안 붙잡고 있던 test 케이스는 큰 데이터를 스택 영역에 할당해주는 것이었다. 해당 부분에서 우리가 가

다시 또 오랜만에 쓰는 TIL이다.. 무한loop에 빠져서 제대로 된 진도가 나가지 않는게 매우 힘들다. 아래 코드가 project 3 에서 실행해야 하는 함수 중에 가장 핵심인 vmtryhandlefault 함수이다. 이 함수를 통해서, 기존의 pml4 기반의 페이지 탐색에 실패했을 때, 새로운 보충 페이지테이블인 spt(supplementalpage_table)에서 검색한다. 그리고 만일 spt에서도 페이지를 찾을 수 없으면, vmdoclaim_page 를 통해서 새롭게 page를 요청하고, pml4를 찾아주는 순서로 코드가 실행되어야 했다. 하지만 커널 패닉이 뜬다. 분명 iskernelvaddr 를 통해서 주소가 제대로 커널 영역에 있는걸 확인하고 vmdoclaim으로 넘어가는데, 계속해서 새로운 페이지만 생성하고 제대로 참조가 되지 않았다. 그렇게 무한루프에 빠졌다. 오늘 이걸 디버깅 하느라 거의 하루를 날렸는데도 여전히 난항중에 있다. 내일은

TIL을 다시 적기 시작한다... 2주차를 진행하다가 음식을 잘못먹고 급성장염으로 몇일간 아프면서 TIL도 같이 중단됐었다. 그리고 그 사이에 벌써 3주차로 넘어왔다. 2주차 내용은 아직 많이 쓰지도 못했는데 말이다. 그래도 다시 써보고자 3주차부터 다시 쓰려고 한다. 2주차 나머지 내용은 나중에 시간이 있을때 별도로 작성하는 걸로 할 예정이다. 오늘로 3주차 3일째이다. 월요일 오후부터 시작해서 3일차이다. 오늘까지 기본적인 이론을 공부했다. 그 내용들을 조금 여기에 정리해고자 한다. 가장 초기의 OS에서 page allocation 방식은 contiguous allocation(연속할당) 방식이었고, 이런 방식은 치명적인 외부 단편화 문제를 발생시켰다. 이러한 문제를 잡기 위해서 메모리를 동일한 크기인 page로 쪼개는 방법이 나왔다. page를 사용하면서 메모리를 100% 만큼으로 사용할 수 있게 되었는데, physical memory에서 여기저기 퍼져있기 때문에 프로

thread 구조체 수정부터 시작하려고 했었던 계획은 실패했다. 코드 여러 구석을 뜯어보고 알게됐다. 이 부분은 userprogram 부분의 핵심인 fork() 함수와 wait()함수 작성이 필수인 부분이었다. 그리고 아직 작성되지 않은 시스템 콜을 작성해나가면서 인수를 하나하나 추가해가는 방식으로 해야 전체적인 그림을 잡을 수 있을 것으로 보였다. 몇일간의 노력이 허무했지만, 다시 가장 처음으로 돌아가 system_call을 작성하는 것 부터 시작했다. 시스템 콜 핸들러 자체는 어려운 함수가 아니었다. interrupt frame에서 레지스터의 정보를 저장하는 필드가 있고, 어떤 순서로 자료가 저장되는지만 파악하면 쉽게 인자를 넘겨줄 수 있었다. 이후에는 각 case 별로 실행되는 함수를 작성했다. 몇 개만 기록으로 남긴다. 현재 프로세스를 종료하는 시스템 콜인데 오늘 팀원들과 얘기하다가 이후에 나오는 fd_table 을 생성하고 이후에 thread를 종료할 때,

5일차. 체력이 급격히 줄어든게 확실히 실감된다. 주변 사람들은 감기가 유행처럼 퍼졌다. 이제 절반인데 피곤하게 느껴지니 체력 안배의 중요성이 조금 더 느껴진다. 오늘은 코드를 직접 짠건 거의 없었다. 팀원들하고 Project 2 를 크게 나눠서 조금씩 진행을 하는 방식으로 진행을 했다. 앞의 system_call 부분은 가볍게 훑어보고 Thread 부분을 우선적으로 봤다. 코드도 작성할 수 있으면 작성하고, 내용에 대해서 서로 나누는 방식으로 하기로 했기 때문. 카이스트에서 진행할때는 하나의 큰 과제로 진행했지만, 인터넷에서 찾은 다른 자료에서는 조금더 작게 쪼개서 Thread 부분을 진행하는 과제로 쪼개져있었기에 그렇게 진행을 했다. User program에서는 child process가 실행될 수 있기 때문에, 이를 OS가 인지할 수 있도록 해야한다. 동시에 프로세스 하나를 담당하는 하나의 Thread에서도 child 에 대한 정보를 담아야 한다. 여러개의 child가

오늘은 argument passing과 user memory 관련 함수를 완성했다. argument_stack()함수를 짜기 위해서 어떻게 구성해야 하는지도 생각하기 위해 굉장히 애를 먹었는데, 동료들과 얘기해가면서 구성을 마칠 수 있었다. 이렇게 구성하였는데, PintOS에서는 메모리영역에서 단순하게 순서대로 집어넣는게 아니라 주소값이 큰 곳에서부터 역순으로 넣는게 난관이었다. 이를 해결하기 위해서 포인터를 잘 사용해야 했다. 결국 memcpy 함수를 사용해서 넣기 때문에, 낮은 주소값을 시작값으로 넣어주는 것이 포인트였는데, for문을 돌릴때 주소값을 먼저 낮춘뒤에 memcpy 함수에 넣어주는 방법으로 해결했다. 한번 argument들을 넣는 것을 해결하고 나니, 뒤에는 똑같은 방법으로 해결할 수 있었다. 임시로 배열을 만들고 메모리에 argument 데이터를 넣을 때마다 그 포인터를 임시 배열에 넣어준 뒤에 그 배열을 새로 넣어주는 방식으로 PintOS 에서 원하는 구

알고리즘 풀고 CS책을 읽다가 둘째날에 회고록을 적는걸 잊었다... 시작하자마자 하루가 빠진게 너무 아쉽지만 그래도 이제는 빠지지 않고 적어보고자 한다. 오늘도 첫째날과 비교해도 딱히 진도가 많이 나가지는 않았다. 코드에 대해서 이해하고, 과제를 차근차근 진행하려고 했는데 여전히 argument들을 유저 stack에 쌓는 과정을 구현하지 못하고 있다. 과제를 진행하면서 우리가 가동할 프로그램이 Userstack을 참조해서 가동될 수 있게 하도록 hex_dump()함수를 추가했지만, 기본적으로 PintOS에서 적절하게 해볼 테스트가 없어서 난관을 마주했다. 인자로 받은 file_name 변수를 그대로 사용해서 argument 에 넣어도 상관이 없는건지, 별도의 buffer 가 필요한건지 고민중이다. 오늘은 일요일이고 하니 여기서 마무리하고 나머지는 내일 팀원들과 함께 이런저런 시도를 해봐야겠다.

핀토스를 공부하면서 간단하게 적기로 했습니다. Thread 를 처리하는 과제를 마치고 WIL을 적었었고, 정리하면서 머릿속에서 정리되는 것을 느꼈다. 그래서 간단하게 나마 조금씩 적기로 했다. 오늘은 Git book을 읽으면서 대체적인 내용을 훑어봤다. Project 2의 과제의 핵심은 바로, userprogram과 I/O를 다루는 것이다. user program을 실행하는 것은 kernel에 의해서 다양한 작업이 발생하는 것이라고 이해했다. kernel도 user program이 실행될 때 다양한 일들이 일어나는데, 이 과정에 대해서 제대로 실행되도록 하는 것이 이번 과제였다. OS의 특성상 커널부분은 고정된 Physical memory 주소를 가지고 있으며, user가 함부로 해당 주소로 접근하거나 수정하는 것을 막도록 되어있다. 이를 위해서 프로그램이 접근이 불가능하도록 메모리 주소를 관리해야한다. 이를 위해서 파일을 수정해 나갈 예정이다. 그리고 user pro

WIL(weekly I learned) 1) 과제개요 : Priority Inversion Problem 해결 이번 과제에서는 Priority inversion Problem 해결하는 것이 목표이며, 이를 위해서 3가지 도네이션 기능을 구현해야 한다. Priority Inversion이란? 우선순위가 높은 thread가 우선순위가 낮은 스레드를 기다리는 현상이다. 아래의 그림을 보자. priority 는 값이 클수록 우선순위가 높은 것을 의미하며 위의 이미지를 보면, 우선순위가 낮은 연두색 L이 실행되는데 우선순위가 높은 H가 Lock을 요청하고 기다리는 상태인데 H보다 낮은 M이 먼저 실행되는 문제가 발생하는데 이를 Inversion이 발생했다고 한다. ![](https: