# OSTEP

34개의 포스트
post-thumbnail

[OSTEP] 물리 메모리 크기의 극복 : 정책

이번 포스트에서는 저번 포스트에서 알아본 디스크 스왑이 되었을 때, 페이지 교체 정책을 어떻게 효율적으로 정할 수 있는지에 대해 알아보겠습니다.시스템의 전체 페이들 중 일부분만이 메인 메모리에 유지된다는 것을 가정하면, 메인 메모리는 시스템의 가상 메모리 페이지를 가져

2021년 8월 12일
·
0개의 댓글
post-thumbnail

[OSTEP] 물리 메모리 크기의 극복 : 메커니즘

우리는 이전 포스트까지 주소 공간이 비현실적을 작아서 모두 물리 메모리에 탑재가 가능하다는 가정을 하였습니다.정확히는, 실행 중인 프로세스의 전체 주소 공간이 메모리에 탑재된다고 가정하고 있었습니다.이제는 그 가정을 완하하겠습니다.이 포스트에서는 다수의 프로세스들이 동

2021년 8월 12일
·
0개의 댓글
post-thumbnail

[OSTEP] 페이징 : 더 빠른 변환

이번 포스트에서는 저번 포스트에서 알아본 페이징의 주소 변환을 더 빠르게 하는 방법을 알아보겠습니다.먼저 저번 포스트에 알아본 바로는 페이징은 성능 저하를 유발할 수 있습니다.페이징은 주소 공간을 작은 크기로 나누고 각 페이지의 실제 위치를 메모리에 저장합니다.이를 저

2021년 8월 10일
·
0개의 댓글
post-thumbnail

[OSTEP] 페이징 : 개요

이번 포스트는 페이징의 기초 개념에 대해 알아보겠습니다.운영체제는 거의 모든 공간관리를 두가지 중 하나를 사용합니다.첫번째는 세그멘테이션에서 보았듯이, 가변 크기의 조각들로 분할하는 것입니다.이 방법은 불행하게도, 단편화라는 태생적인 무제를 가지고 있습니다.두번째 방법

2021년 8월 8일
·
0개의 댓글
post-thumbnail

[OSTEP] 빈 공간 관리

이번 포스트에서는 빈 공간을 관리하는 문제에대해 논의할 것입니다. 세그멘테이션으로 물리메모리를 관리할시에 빈 공간 관리는 어렵고, 외부 단편화가 어느 경우에도 존재하게 됩니다.빈 공간은 다양한 크기의 작은 조각으로 분할되어 결국 단편화되기 때문입니다.빈 공간들의 전체

2021년 8월 8일
·
0개의 댓글

[OSTEP] 주소 변환의 원리

CPU 가상화에서는 시스템 콜이 호출되거나, 타이머 인터럽트가 발생하는 등의 특정 타이밍에 운영체제가 개입하여 문제가 발생하지 않도록 하였다. → 약간의 하드웨어 지원을 받아 효율적을 CPU를 제어하는 가상화 방법을 사용하였다.메모리 가상화에서도 비슷한 전략을 추구할

2021년 8월 1일
·
0개의 댓글
post-thumbnail

[OSTEP] 주소 공간의 개념

여태까지는 CPU 가상화에 대해 알아보았습니다, 이번 포스트부턴 메모리 가상화에대해 알아보겠습니다.초기 컴퓨터는 많은 추상화를 제공하지 않았습니다.초기 컴퓨터의 물리 메모리는 아래의 그림과 같이 생겼었습니다.OS는 메모리에 상주하는 루틴들의 집합이였고, 물리 메모리에

2021년 8월 1일
·
0개의 댓글

[OSTEP] 스케줄링 : 개요

스케줄링을 공부하기 위해서는 context swtiching 같은 low-level 기법에 대해서는 알고있어야한다.모른다면, 이전 글을 참고하여 다시 공부하자.스케줄링 정책은 원칙이라고도 불립니다.high-levle 기법으로, 운영체제 관리 분야에서 비롯되었음.워크로드

2021년 7월 30일
·
0개의 댓글

[OSTEP] 운영체제 개요

프로그램은 매우 단순한 일을 한다.명령어를 실행한다.프로세서는 명령어를 수백만번 fetch하고, decode하고, execute한다.프로세서는 프로그램이 완전히 종료될 때까지 위와 같은 과정을 반복한다.물리적인 자원을 이용하여 일반적이고, 강력하고, 사용이 편리한 가상

2021년 7월 29일
·
0개의 댓글
post-thumbnail

Event-based Concurrency (Advanced)

node.js같은 server-side framework에서 자주 쓰이는 concurrency 방법이다.Event-based Concurrency는 2가지 부분을 다루게 된다.multi-threaded application에서 concurrency를 정확하게 다루는 것

2021년 3월 16일
·
0개의 댓글
post-thumbnail

Common Concurrency Problems

위와같은 어플리케이션에서 deadlock은 총 31개 deadlock이 아닌 버그는 74개이다.첫번째 non deadlock 버그는 MySQL에서 발견한 atomicity-violation bug이다.이 버그는 다른 2개의 thread가 proc-info라는 같은 데이

2021년 3월 5일
·
0개의 댓글
post-thumbnail

Semaphore

semaphore란 sem_wait()과 sem_post()로 우리가 조작할 수 있는 정수값을 갖는 object이다.위처럼 semaphore는 초기화를 해야만 한다.sem_init()으로 초기화를 수행하는데 s라는 semaphore를 1로 초기화 하고, 2번째 인자인

2021년 3월 1일
·
0개의 댓글

Condition Variables

concurrent program을 위한 유일한 요소는 lock뿐만이 아니다.thread들이 실행을 계속할지의 여부를 결정하기 위해서는 condition을 확인해야한다.위의 코드처럼 부모 thread가 자식 thread의 종료를 기다리는 상황에서 단순하게 spin-ba

2021년 2월 17일
·
0개의 댓글
post-thumbnail

Lock-based Concurrent Data Structures

자료구조에 lock을 추가하여 thread에서 사용할 수 있도록 하면 thread 구조에 안정성을 추가할 수 있다. 따라서 lock이 정확하게 어떻게 추가되는지가 데이터 구조의 정확성과 성능을 결정한다. 결론적으로 특정한 자료구조에 lock을 추가할 때 정확하게 동작

2021년 2월 16일
·
0개의 댓글
post-thumbnail

Lock

lock의 목적은 crital section이 atomic하게 동작하는 것을 보장하기 위함이다.lock variable이 lock의 상태를 지니고 있다.available 아무런 thread도 lock되지 않았음acquired critical section에서 한개의

2021년 2월 9일
·
0개의 댓글
post-thumbnail

Concurrency: An Introduction

thread라는 것에 대해서 알아볼 것이다.thread는 개별적으로 동작하는 프로세스와 많이 닮아 있다. 하지만 같은 address space를 공유해서 같은 data에 접근한다는 점에서 프로세스와 차이가 있다. 이 공유되는 data를 critical section이라

2021년 2월 8일
·
0개의 댓글
post-thumbnail

Swapping: Policy

물리적 메모리에 free space가 아주 많다면 새로운 page를 메모리에 담는 작업이 어렵지 않다. 하지만 물리적 메모리에 free space가 없다면 어떻게 해야할까?기존의 page를 메모리에서 제거할 때 어떤 기준으로 page를 메모리에서 제거하는걸까?page

2021년 2월 5일
·
0개의 댓글
post-thumbnail

Swapping: Mechanism

이전까지의 내용에서는 모든 address space가 물리적 메모리에 정확하게 들어맞는다고 가정하고 이론을 알아보았다. 그리고 모든 pages가 메모리에 위치해 있다고 알고 공부하였다.하지만 크기가 큰 address space를 사용하기 위해서는 당장 필요하지 않은 a

2021년 2월 4일
·
0개의 댓글

Paging: Smaller Tables

page table의 두번째 문제점인 너무 커서 메모리를 많이 잡아먹는다는 문제점을 살펴보자. 이러한 array-based page table(linear page table)의 문제를 해결하기위한 page table을 더 작게 만들 수 있는 방법은 무엇이며, 더 작아졌을 때 발생하는 비효율은 무엇일까...? Simple Solution: Bigger ...

2021년 1월 19일
·
0개의 댓글
post-thumbnail

Paging: Faster Translations (TLBs)

가상 메모리를 지원하는 핵심 mechanism으로 paging을 활용하면 고성능 오버헤드가 발생할 수 있다.address space를 고정된 크기로 작게 나누는 paging은 거대한 mapping information을 필요로 한다. 이런 mapping informat

2021년 1월 18일
·
0개의 댓글