어나이(어제의 나를 이기자)

마구니 게임 프로젝트를 완성하고 나서 우리 게임에 대한 성능 테스트를 시도해보고자 했다. 사실 프로젝트 설계단계에서 테스트를 하는 것이 맞지만 시간 상 어쩔 수 없이 .. 프로젝트가 끝나고 한다. 이것또한 의미가 있다고 생각한다.  webRTC 성능 테스트를 하는 이유는 2가지가 있다.서버를 어느정도의 크기로 구축해야 할지 알기 위해서구축한 서버가 어느정도의 부하를 감당할 수 있을지 알기 위해서1번은 설계 단계에서 하는 것이 좋겠지만 2번은 MVP가 완성된 후에 하는 것이 좋다고 생각한다.최적의 서버로 미디어서버 EC2 와 클라이언트 EC2를 각각 구축한 후, chrome://webrtc-internals 을 통해 테스트를 해보자. https://www.youtube.com/watch?v=fojCaHHJ..

가상 메모리와 물리 메모리, 디스크와 스왑디스크, 페이지와 프레임, 보조 페이지 테이블과 pml4의 개념을 공부하며 프로젝트3 가상 메모리를 구현했다. 아래 그림은 함수의 흐름을 적어놓고 함수가 어떤 역할을 하는지 간단하게 설명했다.    1. process exec -> load -> page fault -> lazy load   2. process fork   3. swap out  case   4. swap out & destroy   5. mmap & munmap    아래는 pintos 과제를 구현한 깃허브 레포지토리로 참고하셔도 되나 설명이 부족할 수 있습니다.또한 모든 내용을 잘못된 정보가 있을 수 있으므로 확인이 필요합니다.  https://github.com/wookhyunKim/pint..

이번 포스팅은 user 가 mmap & munmap 시스템 콜을 호출할 때 상황을 보려고 한다.프로젝트 2 시스템 콜과 같이 시스템 콜 핸들러에 mmap 과 munmap을 추가하고 do_mmap, do_munmap으로 운영체제가 유저의 요청을 처리한다. mmap과 munmap은 디스크로 부터 파일 내용을 메모리에 적재할 때 사용하며 파일을 건드리는 부분에서는 lock이 필요하다.    시스템 콜  system call handler{#ifdef VM case SYS_MMAP: f->R.rax = mmap_syscall(f->R.rdi,f->R.rsi,f->R.rdx,f->R.r10,f->R.r8); break; case SYS_MUNMAP: munmap_syscall(f->R.rdi); break..

이번 포스팅은 효율적으로 메모리 관리를 하기 위해 물리메모리에서 frame을 swap_out 하는 것을 할 것이다. LRU(Least Recently Used)는 페이지 교체 알고리즘중 하나로, 가장 오랫동안 사용되지 않은 페이지를 교체하는 방식입니다. 이 알고리즘은 메모리에서 사용되지 않은 페이지를 교체하여, 효율적인 메모리 관리와캐시 히트율 향상을 목표로 합니다.LRU 알고리즘의 기본 개념가장 최근에 사용된 페이지는 계속 유지하고, 오랫동안 사용되지 않은 페이지는 교체 대상으로 선정합니다.Least Recently Used*라는 이름 그대로, 가장 최근에 사용되지 않은 페이지를 교체합니다.LRU는 사용된 페이지의 시간 순서를 유지하면서, 오래 사용되지 않은 페이지를 찾기 위한 정보를 기록하는 방식입니..

VM 프로젝트 두 번째 포스팅은 프로세스의 execute 과정을 알아보려고 한다.프로세스의 exec는 user가 exec라는 시스템 콜을 커널에게 보내고 이를 받아서 커널이 process_exec 함수를 실행한다.process_exec 함수 내에 load 함수가 있는데 이는 실행가능 목적파일의 ELF 데이터들을 프로세스의 가상메모리로 로딩하는 함수이다.- CSAPP 7장 링커 참고  대부분의 정보는 pintOS 스켈레톤 코드에 로딩하는 코드가 있지만, User stack 과 kernel memory에 User Pool 부분에서 해주어야 하는 부분이 있다.    process_exec의 흐름을 살펴보면 다음 그림과 같다.  메모리를 효율적으로 관리하기 위해 demand paging일 때 가상 메모리와 물리..

PintOS  세 번째 과제에서는 가상 메모리를 다루는 것이다. 그 중 가장 처음에 해야할 것은 보조 페이지 테이블(supplemetal page table)을 만드는 것이었다. 보조 페이지 테이블을 spt라고 하겠다. spt는 demand page할 때 pml4에 매핑을 하기 위해 또는 물리 메모리에 load 하기 위해 필요한 임시 거처라고 할 수 있다.spt는 다양한 자료구조로 구성할 수 있는데 이전에 스레드를 관리했던 연결리스트, 배열, 해시, 비트맵 등이 있겠지만 이번에는 해시테이블 자료구조를 사용하고 체이닝 기법으로 해시값이 같은 페이지를 관리하도록 spt 를 구성했다. 해시 테이블 장점 시간 복잡도가 O(1) 이므로 빠른 검색, 삽입, 삭제가 가능하다. 또한 배열의 인덱스가 아닌 것으로 탐색을..

시스템 콜 (1) 에 이어 파일을 다루는 함수 파일은 공유자원이기 때문에 여러 프로세스가 같은 파일을 여는 것은 가능하지만 수정하는 것은 하나의 프로세스만 가능해야 한다. 따라서 project 1 에서 했던 lock의 개념이 필수적이다. syscall_init에  lock_init(&filesys_lock); 을 추가한다. 또한 모든 함수들은 전방선언이 필수이므로 syscall.h에 선언해주어야 한다.    1. 파일 생성, 삭제bool create_syscall(const char *file, unsigned initial_size){ check_address(file); lock_acquire(&filesys_lock); bool success = filesys_create(file,initial_s..

user program은 컴퓨터 전체를 소유한다는 환상 하에 쓰여진다. 예를 들어서 메모리, cpu 등 자원들을 사용하는데 우리는 이것을 추상화 하여 각 프로세스가 진짜로 자원을 다 사용하고 있다고 착각하게 만든다. 또는 이 환상을 만족시키는 방향으로 관리를 해야 한다. 따라서 프로세스가 하면 안되는 작업을 하기 위해 시스템 콜을 호출하게 된다. 시스템 콜이란 유저프로그램이 못하는 작업을 커널에게 부탁을 하는 것이라고 생각할 수 있다. 따라서 project 2 의 목표는 OS와 user program이 상호작용을 할 수 있도록 시스템 콜 함수들을 구현하는 것이다.    위의 그림을 간단히 설명해보자면,유저프로그램이 exec() 함수를 실행한다.exec()는 유저프로그램이 실행하지 못하는 작업이므로 커널에..

실행 가능 목적파일을 실행하기 위해서, 쉘은 로더 loader라고 알려진 메모리 상주 운영체제 코드를 호출해서 이 프로그램을 실행한다. 모든 리눅스 프로그램은 execve 함수를 호출해서 로더를 호출할 수 있으며, 로더는 디스크로부터 실행 가능한 목적파일 내의 코드와 데이터를 메모리로 복사하고 이 프로그램의 첫 번째 인스트럭션, 즉 엔트리 포인트로 점프해서 프로그램을 실행한다. 이와 같은 프로그램을 메모리로 복사하고 실행하는 과정을 로딩이라고 부른다. - CSAPP 7장 링커 참조   왼쪽 그림의 바이너리 데이터는 오른쪽그림의 아래부분에 채워진다. 이 과정을 로딩이라고 한다. 로딩은 pintos 코드에서 지원을 한다고 하지만, User stack 영역을 채워주는 것이 project 2 의 첫 번째 과제였..

CPU 스케줄링 중 하나의 기법인 우선순위 스케줄링은 비선점(Non- Preemptive) 방식이다. 따라서 CPU를 점유하고 있는 스레드가 우선순위가 제일 높으면, 이 스레드의 모든 작업이 끝나야 CPU를 양보한다. 또한 현재 실행 중인 스레드의 우선순위보다 높은 우선순위를 가진 새로운 스레드가 생성되었을 때, 바로 현재 스레드는 즉시 CPU를 양보한다.           여러 스레드가 동시에 같은 데이터를 조작할 때 타이밍이나 접근 순서에 따라 결과가 달라질 수 있는 상황인 경쟁 조건을 방지하기 위해 OS는 여러 스레드를 동시에 실행해도 공유 데이터의 일관성을 유지하는 동기화(synchronization) 작업을 해야한다. 이 때의 공유 데이터를 임계 영역(critical section)이라고 한다...