https://jukim2.github.io/categories/os/Recent content in OS on GameDev DocsHugoenSun, 23 Jun 2024 23:00:00 +0900https://jukim2.github.io/docs/cs/os/trap/Sat, 06 Apr 2024 14:00:00 +0900https://jukim2.github.io/docs/cs/os/trap/서론 link이번에 소개해드릴 내용은 xv6의 Trap에 관한 내용입니다. Trap에 대해서는 아래에서 자세하게 설명드리겠지만 간단하게 말씀드리자면 system call, exception, device interrupt를 통합하여 부르는 단어입니다. 본 글에서는 risc-v의 xv6 운영체제에서 Trap 중에서 system call에 집중하여 Trap이 어떻게 발생되고 핸들링되는지 설명해드리겠습니다. 개념 link우선 xv6에서 사용되는 용어들에 대해서 말씀을 드리겠습니다. Mode linkApplication과 OS는 강력하게 ‘분리’되어있습니다. 왜냐하면 어떤 Application에서 문제가 발생했다하더라도 운영체제가 터지거나 다른 프로세스에 영향이 가면 안되니말입니다. 이러한 분리는 Mode라는 것을 통해 이뤄집니다. RISC-V같은 경우 세가지 모드가 있습니다.https://jukim2.github.io/docs/cs/os/cpu_sched_one/Mon, 08 Apr 2024 01:00:00 +0900https://jukim2.github.io/docs/cs/os/cpu_sched_one/서론 link 한개의 코어는 한번에 하나의 프로세스만 돌릴 수 있기때문에 언제 어떤 프로세스를 돌릴 지 정확히 파악해야합니다. 이 목적을 달성하기 위해서 필요한 것이 바로 CPU scheduling입니다. 이번 글에서는 가장 간단한 CPU scheduling부터 시작해서 I/O aware STCF이라는 스케줄링 기법까지 다루려고 합니다. 그 후 다음 글에서 최근에 쓰이는 더 복잡한 스케줄링 기법에 대해 다루겠습니다. 용어 정리 link 우선 글에 등장하는 몇 가지 용어들을 정리하고 넘어가겠습니다. Non preemptive scheduling linkNon preemptive scheduling은 현재 CPU에서 돌아가고 있는 프로세스를 쫓아내거나 밀어내고 다른 프로세스가 들어갈 수 없는 스케줄링 기법을 의미합니다.https://jukim2.github.io/docs/cs/os/qemu_gdb/Fri, 05 Apr 2024 14:00:00 +0900https://jukim2.github.io/docs/cs/os/qemu_gdb/시작 link이번에 qemu를 이용해서 risc-v에서 돌아가는 xv6이라는 운영체제에 대해서 공부하고있는데요. 문제는 현재 맥에서 xv6를 돌리다보니 gdb를 이용해서 디버깅할 수 없다는 것이었습니다. 저는 리눅스 컴퓨터가 없는 관계로 utm으로 리눅스 가상머신을 돌리거나 도커를 이용해야했는데 도커가 훨씬 간편하게 돌릴 수 있을 것 같아 도커에 우분투를 설치하고, 거기서 GDB를 이용하여 xv6를 디버깅하기로 결정했습니다! 진행 link컨테이너 만들기 link우선 도커 컨테이너를 만들었습니다. 지금은 간단하게 디버깅용으로 사용할 우분투 환경이 필요한 것이니 따로 dockerfile이나 docker-compose같은 것은 구성하지 않고 바로 도커 컨테이너를 만들었습니다.https://jukim2.github.io/docs/cs/os/cpu_sched_two/Tue, 09 Apr 2024 01:00:00 +0900https://jukim2.github.io/docs/cs/os/cpu_sched_two/서론 link 지난 글에서 여러가지 CPU 스케줄러를 제시하면서 스케줄러가 가져야할 특성들에 대해서 논의해보았습니다. 그리고 마지막으로 I/O aware STCF을 제시했지만 현실적으로 각 job의 runtime을 아는 것은 불가능하기에 스케줄러로 채택하기에는 무리가 있었죠. 그렇다면 어떤 스케줄러를 생각할 수 있을까요? 한번 일반적으로 적용가능한 스케줄러를 생각해보고, 리눅스에서는 어떤 것을 채택했는지 알아보겠습니다. MLFQ (Multi-Level Feedback Queue) link 이전에 보았던 Priority Scheduling Queue를 기억하시나요? job마다 priority를 부여한 뒤 그 priority에 따라서 스케줄링을 했었죠. 그런데 그 때는 priority가 한번 부여되고나면 조절하지는 못했습니다.https://jukim2.github.io/docs/cs/os/xv6_system_call/Sun, 07 Apr 2024 11:00:00 +0900https://jukim2.github.io/docs/cs/os/xv6_system_call/들어가며 link 이 글은 xv6-Trap 글에서 다룬 내용을 기반으로 새로운 system call을 만들어보는 과정을 담은 글입니다. 이번 글에서 만들어볼 system call은 총 두 가지입니다. 하나는 sys_kbdints()라는 keyboard interrupt의 개수를 반환해주는 함수이고, 하나는 sys_time()이라는 mtime register의 값을 반환해주는 함수입니다. sys_kbdints에 비해 sys_time이 특이한 점은 mtime 레지스터가 m-mode에서만 읽을 수 있는 레지스터라는 점입니다. 그래서 sys_time()을 구현하기 위해서는 추가적인 작업을 해주어야합니다. 이 점에 집중하여 글을 보시면 좋을 것 같습니다. System call 구현 해보기 link 1.https://jukim2.github.io/docs/cs/os/edf/Mon, 29 Apr 2024 12:00:00 +0900https://jukim2.github.io/docs/cs/os/edf/들어가며 link 안녕하세요 cpu scheduling2 글에서 보았듯이 cpu에서 돌아갈 프로세스를 선택하기 위해서 os는 스케줄러를 운영했습니다. 그리고 매우 다양한 종류의 스케줄러들이 있었죠. 이번에는 그러한 지식을 바탕으로 저의 커스텀 스케줄러를 xv6 운영체제 안에 넣어보려고 합니다. 이번에 적용할 스케줄러의 이름은 EDF(Earliest Deadline First) 스케줄러인데 EDF란 무엇이고, 기존 스케줄러 코드는 어떻게 구성되어있나 살펴본 뒤 EDF를 구현하는 과정을 살펴보겠습니다. 스케줄링 과정 알아보기 link Real-time linkEDF에 대해 다루기 이전에 Real-time system에 대해 말씀드리려고 합니다. Real-time system이란 특정 시간 제약 안에 입력에 대해 응답하는 시스템입니다.https://jukim2.github.io/docs/cs/os/virtual_memory/Mon, 15 Apr 2024 15:00:00 +0900https://jukim2.github.io/docs/cs/os/virtual_memory/서론 link 프로그래밍을 계속해서 공부하다보면 virtual memory를 접하게 됩니다. 저도 처음 접했을 때는 아 어떻게 가상으로 메모리를 쓰나보다, 그러면 뭔가 좋은가보다하고 넘어갔던 기억이 있습니다. 이 글에서부터 시작해 여러 글을 통해 그렇게 넘어갔던 virtual memory의 모든 것에 대해 알아보려고 합니다. 우선 이 글에서는 virtual memory가 어떤 방식으로 발달해왔는지 알아보겠습니다. 목표 link 우선 간단하게 Virtual memory를 사용해서 달성하고자 하는 목표들에 대해서 알아보죠. Transparency Efficiency Protection 이렇게 세가지가 있는데요, Transparency는 프로세스는 메모리가 공유되고 있는지 알지 못하는 것을 의미하고, Efficiency는 fragmentation이라는 것을 줄여서 효율적으로 메모리를 사용하는 것을 의미하고, Protection은 말 그대로 프로세스와 OS를 다른 프로세스로부터 보호하는 것을 의미합니다.https://jukim2.github.io/docs/cs/os/fat/Sun, 23 Jun 2024 23:00:00 +0900https://jukim2.github.io/docs/cs/os/fat/들어가며 link 안녕하세요 오늘은 xv6에 FAT이라는 새로운 파일 시스템을 넣어보려고 합니다. 그전에 xv6의 기존 file system에 대해 알아보자면 다음 그림과 같습니다. filesystem에 관한 정보를 저장하고있는 superblock과 Inode 블럭에 관한 정보를 저장하는 Inode Bitmap 블럭과 Indoe블럭들, Data 블럭에 관한 정보를 저장하는 Data Bitmap 블럭과 Data 블럭들이 있죠. 이번에 도입할 FAT filesystem이란 File Allocation Table(FAT)이라는 배열 형태의 새로운 자료구조를 활용하여 만약 어떤 파일이 44, 48, 49의 데이터 블럭을 사용한다고 하면 FAT[44] = 48, FAT[48] = 49, FAT[49] = 0 이런 형태로 해당 파일의 한 블럭의 다음 블럭을 저장해두는 시스템입니다.https://jukim2.github.io/docs/cs/os/mmap/Sun, 21 Apr 2024 18:00:00 +0900https://jukim2.github.io/docs/cs/os/mmap/서론 link 안녕하세요 이번 글에서는 mmap에 대해 알아보려고 합니다. 저는 이번에 mmap에 대해 배우기 전까지는 아예 mmap에 대해 알지 못했고, 사용해본적도 없는데 알고보니 상당히 중요한 내용이었습니다. 이 글을 읽는 분들도 이번 기회를 통해서 mmap에 대해 알게되면 좋겠습니다. mmap이란? link mmap이란 memory mapping의 줄임말로, RAM의 특정 메모리 공간을 프로세스가 할당받아서 사용하는 것을 말합니다. mmap은 두 가지 방식으로 동작하는데 각각 anonymous mapping과 file mapping입니다. file mapping을 하게되면 디스크에 있던 파일 데이터가 메모리에 올라간 후, 그 메모리 영역을 프로세스에 할당해주는 것 입니다.https://jukim2.github.io/docs/cs/os/swap/Sun, 21 Apr 2024 21:00:00 +0900https://jukim2.github.io/docs/cs/os/swap/서론 link 컴퓨터의 여러 프로세스들이 열심히 돌다보면 메모리가 부족해지는 순간이 올 수도 있을 것입니다. 여러분도 컴퓨터를 사용하다가 갑자기 렉이 걸리면서 마우스가 묵묵부답인 순간들을 본 적이 있듯이 말이죠. 그럴 때를 대비하여 컴퓨터에는 Swapping이라는 기법이 있습니다. 메모리의 특정 부분을 디스크에 빼뒀다가 다시 꼈다가하는 식으로 메모리와 디스크 사이를 swap하는 것이죠. 메모리가 disk를 사용한다는 것은 역으로 생각하면 메모리가 disk의 cache로 동작한다고 볼 수도 있을 것입니다. 그러면 이번 글에서는 이 swapping은 언제, 어디서, 어떻게 일어나는지 한번 알아보겠습니다.https://jukim2.github.io/docs/cs/os/paging/Mon, 22 Apr 2024 12:00:00 +0900https://jukim2.github.io/docs/cs/os/paging/들어가며 link 지난 번에는 virtual memory에서 virtual memory의 필요성과 구현 방법에 대해서 알아보았었습니다. static relocation과 dynamic relocation에 대해 알아보고, dynamic relocation의 구현 방법인 Fixed partition, segmentation에 대해서 알아보았었죠. 그렇지만 segmentation 기법 역시 단점이 있었기에 이번 글에서는 오늘날 사용되는 paging 기법을 소개해 드리려고 합니다. Paging link 구현 방법 linkPaging기법은 간단하게는 segmentaton 기법을 더 쪼갰다고 생각하면 됩니다. segmentation에서는 segment 단위로 프로세스에게 메모리를 주었지만 Paging은 page 단위로 메모리를 주는 것입니다. 그리고 간단하게 용어를 정리하자면, page와 frame이라는 단어가 많이 쓰일 것인데 page는 가상 메모리를 이루는 단위, frame은 물리 메모리를 이루는 단위입니다.https://jukim2.github.io/docs/cs/os/tlb/Mon, 29 Apr 2024 02:00:00 +0900https://jukim2.github.io/docs/cs/os/tlb/들어가며 link안녕하세요 이번에는 TLB에 대해서 간단하게 이야기해보려고 합니다. 한번 Paging 글에서 Paging 기법에 대해서 다룬 적이 있었죠. 그런데 이 Page 기법을 이용했을 때 page table에서 매칭되는 page를 탐색하는 것이 생각보다 비용이 많이 드는 작업입니다. 왜냐하면 Paging 글에서 소개해드리지는 않았지만 실제로 page table은 네단계로 구성되기도하여 한번 virtual address에 대응되는 PTE(page table entry)를 찾기 위해서 4번의 메모리 접근을 해야하기때문입니다. 그래서 사람들이 생각한 것이 몇 개의 virtual address에 대해 그에 대응되는 PTE를 저장해놓는 장치가 있으면 적어도 그 virtual address에 대해서는 여러 번의 메모리 접근 없이 바로 PTE를 얻을 수 있으니 유용하지 않을까?https://jukim2.github.io/docs/cs/os/monitor/Tue, 09 Apr 2024 01:00:00 +0900https://jukim2.github.io/docs/cs/os/monitor/Monitor란 프로그래밍 언어 자체에서 제공하는 공유 자원에 대한 동기화 메커니즘입니다. 공유 자원에 접근하는 Procedure들이 존재하는데 이 Procedue는 한번에 하나만 실행되도록 조절됩니다. Monitor 안에는 Condition variable이 존재. 그래서 조작 가능 예시는 아래와 같음 insert라는 procedure를 보면 한번에 하나만 접근되도록 막아놓았음. 만약 들어갔는데 막혀있으면 await로 대기열에 추가됨. await()와 signal()을 통해서 대기열에 추가되고 빠져나오고 함. import java.util.LinkedList; import java.util.Queue; import java.util.concurrent.locks.Condition; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; public class ProducerConsumerMonitor { private Queue<Integer> buffer; private int maxSize; private Lock lock; private Condition notFull; private Condition notEmpty; public ProducerConsumerMonitor(int size) { this.