WOONY's 인사이트

Page Cache and Buffer Cache page cache VM의 페이징 시스템에서 사용하는 페이지 프레임을 캐싱 관점에서 설명하는 용어 memory-mapped I/O를 쓰는 경우 file I/O에서도 page cache 사용! Memory-mapped I/O File 일부를 vm에 매핑 매핑시킨 영역에 대한 메모리 접근 연산은 파일 입출력을 수행하게 한다. Buffer cache 파일 시스템 통한 I/O 연산은 메모리 특정 영역인 buffer cache 사용 파일 사용의 locality 활용 한번 읽어온 블록에 대한 후속 요청시 버퍼 캐시에서 즉시 전달 모든 프로세스가 공용으로 사용하는 캐시! Replacement algorithm 필요(LRU, LFU 사용 가능 → 모든 정보를 운영체제에..

저번 시간에는 mmap/munmap을 통해 가상 메모리에 페이지를 할당해주는 방법에 대해 배웠다. mmap에 대해 궁금한 점을 마저 정리하고 내일 swap in/out으로 넘어가련다. 정리 1: mmap으로 페이지를 할당받으면 힙/스택 중 어느 공간에 페이지가 할당되는가? 결론부터 말하면 mmap으로 페이지를 할당받으면 힙도 스택도 아닌 공간에 할당된다. 아래 그림에서도 나와있듯 mmap은 file의 offset 위치부터 length 길이만큼 읽어들여 가상 메모리에 매핑한다. 이때 주의할 점은 첫번째로 매핑할 때는 물리 프레임에는 올리지 않는다는 점. 이 역시 malloc()과 차이라고 할 수 있는데, malloc()은 힙 공간에 인자로 넣어주는 사이즈만큼의 공간을 할당한다. 공부하면서 느끼는 건데, m..

첫 번째 과제는 supplemental page table 구현이다. 이를 위해 supplemental page table이 무엇인지 먼저 간단히 살펴보자. supplement page table은 이전에 정리했던 개념인 다단계 페이지 이제 과제 개요를 살펴본다. 0. 과제 개요 Implement supplemental page table management functions in `vm/vm.c`. 우리의 핀토스는 pml4라는 페이지 테이블을 갖고 있는데 얘는 가상 메모리와 물리 메모리 간 매핑을 관리한다. 하지만, 이것으로 충분치 않음. 이전 섹션에서 논의했듯, 우리는 page fault와 자원 관리를 다루기 위해서 각각 페이지에 대한 추가 정보를 들고 있는 supplementary page tabl..

한동안 TIL 정리가 많이 밀렸다. 다시 정신차리고 가보자!! 메모리 관리 3 Multilevel Paging and Performance address space가 커지면 다단계 페이지 테이블이 필요하다. (why? 사용하지 않는 공간을 엔트리로 넣어야 하니 페이지 테이블이 커져서 비효율 증가) 이러면 페이지 테이블에 여러 번 접근해야 한다. ex) 4단계 페이지 테이블이면? 4번 접근해야 한다. 그런데도 다단계 페이지 테이블을 쓸 수 있는 이유는? TLB! ex) 메모리 접근 시간이 100ns, TLB 접근 시간이 20ns이고 TLB hit ratio = 98%라면? effective memory access time = 0.98 * 120(100*1 + 20*1) + 0.02 * 520(100*4 ..

오늘은 갓효경 강의를 들었다. 오늘 효율이 개쌉망이라 강의 두 개 들은게 전부네..ㅁㅊ.. 노션에 정리해서 여기다 옮겨야 하는데, 일단은 링크로 대체..강의 다 듣고서 리마인드할 때 정리하자! (이제까지 썼던 TIL 중 역사상 가장 짧은 TIL이 될 것 같아..키워드만 조금 정리) 메모리 관리 1 논리 주소 vs 물리 주소 논리 주소: 각 프로세스마다 독립적으로 갖는 주소 공간(0번지부터 시작) cpu가 보는 주소는 여기에 해당 물리 주소: 메모리에 실제로 올라가는 위치 주소 바인딩: 프로그램이 메모리 내 물리 주소 어디에 올라가는지를 결정하는 것 symbolic addr => logical addr => physical addr 과정을 거치는데, 이 중 logic => physic 이 부분에 해당하는 ..

저번 글에서 핀토스 부팅부터 시작해 시스템콜이 호출되기까지의 과정을 정리했다. 다시 보니 빠진 내용이 많아 수정하면서 보완할 예정. 저거 공부하느라 한동안 밀렸던 과제를 다시 진행한다. 오늘은 저번에 구현한 exit() 수정 및 write(), open(), close(), filesize(), seek(), tell()을 구현해보자. 1. 과제 구현 exit() & thread 구조체 수정 지난 번 글에서 exit()을 미처 완성하지 못한 것을 깨달았다. 여기서 수정 과정에 대해 기록한다. exit()은 현재 프로세스를 종료시키는 시스템 콜이다. 이때 종료시키려는 스레드의 status를 바꿔줘야 한다. 따라서 아래처럼 exit_status 멤버를 스레드 구조체에 하나 만들어준 다음, exit에서 해당 ..

시스템 콜 과제 이어서. 한양대 핀토스 pdf에서는 이 챕터를 process hierachy라고 명명하는데, 그냥 system call로 이어서 하겠다. 지난 과제에서는 halt(), create(), remove(), exit()에 대해 정리했다. 여기서 잠시 리마인드해보기. 이 과제를 왜 하고 있지? 지금 우리가 하는 일은 시스템 콜 핸들러를 구현하는 것이다. 왜 이게 필요하지? 유저 프로그램에서 운영체제 혹은 하드웨어에 직접 접근하지 않고 커널에다가 요청(시스템 콜)만 하면 운체가 시스템 콜 핸들러를 이용해 내부적으로 작업하고 결과값만 휘리릭~하고 넘겨주기 위한 것이다. 이 작업으로 유저 프로그램은 복잡한 아랫단까지 내려갈 것 없이 결과만 호로록 받으면 되는 것! 뿐만 아니라 이렇게 작업하면 유저 ..

대망의 핀토스 프로젝트가 시작됐다. 오늘은 시작한지 5일차. 운영체제 이론 공부(~데드락)를 마치고 과제를 보니까 이건 뭐 또다른 신세계.. 하지만 조급해하지 않고 차근차근 공부해보자. 과제 설명부터 보겠다. (과제 링크는 여기) Reimplement timer_sleep(), defined in devices/timer.c. 현재 코드는 작동하나, 지금 코드는 busy-wait 방식이다. 이는 현재 시간(tick)을 계속 체크한 뒤, 충분한 시간이 지나기 전까지 계속해서 thread_yield() 함수를 호출하는 루프를 돈다. 이러한 busy waiting을 피하기 위해 코드를 다시 짜라. 쓰레드 호출을 최소한 x 시간이 지난 후에 진행할 수 있도록 지연해라. 만약 시스템이 idle 상태가 아니라면, ..