D cron

Memory Management 3 Multilevel Paging and Performance Address space가 더 커지면 다단계 페이지 테이블이 필요 4단계 페이지 테이블을 사용하는 경우 주소변환하는데 4번 + 직접 메모리 접근 1번 = 총 5번의 메모리 access가 필요함 메모리 접근 시간이 100ns, TLB 접근 시간이 20ns, TLB hit ratio가 20%인 경우 effective memory access time = 0.98 x 120+0.02 x 520 = 128ns 결과적으로 주소 변환을 위해 걸리는 시간은 28ns이다. Valid(v) / Invalid(i) Bit in a Page Table Memory Protection page table의 각 entry마다 아래의..

Memory Management 2 Paging paging 프로세스의 virtual memory를 동일한 사이즈의 page 단위로 나눔 virtual memory의 내용이 page 단위로 noncontiguous(불연속)하게 저장됨 일부는 backing storage에, 일부는 physical memory에 저장 Basic Method physical memory를 동일한 크기의 frame으로 나눔 logical memory를 동일 크기의 page로 나눔(frame과 같은 크기) 모든 가용 frame들을 관리 page table을 사용하여 logical address → physical address로 변환 External fragmentation 발생 안함, Internal fragmentation ..

Memory Management 1 Logical vs Physical address Logical address (=virtual address) 프로세스마다 독립적으로 가지는 주소공간 각 프로세스마다 0번지부터 시작 CPU가 보는 주소는 logical address이다. Physical address(DRAM) 메모리에 실제 올라가는 위치 Logical address와 Physical address는 어떻게 연결될까? A. 주소 바인딩을 통해서 어떤 프로그램이 물리적인 메모리 어디에 올라갈지 결정하는 것 Symbolic Address(변수 이름, 함수 이름) → Logical Address(숫자 주소) → Physical address(실제 주소) 주소 바인딩(address binding) logic..

Project1: priority schedule(3) Priority Inversion Problem 문제 : priority 높은 thread가 priority가 낮은 thread를 기다리는 현상 L, M, H는 thread의 이름이라고 하자. 그리고 우선순위는 H가 가장 높고, L이 가장 낮다. 지금 M보다 H가 우선순위가 높은데, L이 lock을 가지고 있기 때문에 H는 실행되지 못하고, L보다 우선순위가 큰 M이 먼저 실행된다. H는 M이 다 끝날때까지 기다려야 한다. 해결책 : priority donation H이 lock을 획득하려고 요청할 때, L에게 자신의 priority를 donate(기부)한다. 이렇게 되면 M보다 H가 먼저 실행되어서 문제를 해결할 수 있다. 그러나 이렇게 간단하게 ..

Project1: priority schedule(2) 이번엔 무엇을 바꿔볼까? 이번에는 Synchronization과 관련된 도구들의 scheduling 방식을 살펴보자. 그 도구들은 semaphore, lock, condition variables가 존재한다. 그런데 현재 PintOS는 여러 thread들이 semaphore, lock, condition variables를 얻기 위해 기다릴 경우 먼저 온 놈이 먼저 사용하는 FIFO 방식을 사용하고 있다. Synchronization 도구들을 기다릴 때, 우선순위가 가장 높은 therad가 CPU를 점유하도록 구현해보자. Semaphore 하나의 공유자원을 사용하기 위해 여러 thread가 sema_down 되어 대기하고 있다고 할 때, 이 공유자원..

Project1: priority schedule(1) 문제 현재 PintOS는 scheduling을 어떻게 하고 있을까? 앞선 포스트에서 살펴보았듯이, 현재 PintOS는 Round-Robin방식을 채택하고 있다. 할당된 시간 4 tick이 지나면 running thread는 다른 thread에게 선점당한다. PintOS는 새로운 thread를 ready_list에 넣을 때 항상 맨 뒤에 넣는다. 그리고 ready_list에서 다음 CPU 할당할 thread를 찾을 때에는 항상 맨 앞에서 꺼낸다. 이 방식은 thread들 간의 우선순위 없이 ready_list에 들어온 순서대로 실행된다. 제대로 된 우선순위 scheduling이 이루어지지 않고 있다! 해결책 우선순위에 따라 scheduling을 하도록..

Project1: Alarm Clock PintOS에서 thread와 process의 관계 실제 OS에서는 하나의 process 안에 여러 개의 thread가 존재할 수 있으며, 이 thread들은 같은 virtual address space를 공유한다. PintOS에서는 구현을 단순화하기 위해서 하나의 process에 하나의 thread만 있도록 구성되어 있다. PintOS에 한해서는 process = thread라고 생각해도 무방하다. 실제 코드에서 pml4(특정 process의 virtual address 정보를 담고 있는 테이블)등 process가 가지고 있어야 할 내용을 thread struct가 가지고 있다. 현재 PintOS의 Alarm Clock 방식, 문제점 Alarm Clock은 자고 ..