[Week7] OS 강의

안나경·2024년 3월 5일

크래프톤정글

목록 보기
41/57

10시 반 OS 강의

하 다 까먹엇다

OS를 어떻게 접근해야하냐?

보통 bottom-up으로
아래서부터 디테일을 보고 취합하겠지만
OS 공부의 중요한 건
Top-down 식 접근이라 생각함

무슨 필요성 때문에 OS를 이렇게 디자인 했는가?

를 알아야,
이를 활용한 웹서버 설계 시에도 도움이 됨.


OS 추상화 시 고려해야하는 점.

OS 추상화 시
요소들을 네모의 블록으로 나타냄.

그냥 네모가 편해서 이렇게 그린게 아님.
이러한 모든 구역들은 data와 code 두 부분으로 이루어진
코드 블록을 추상화한 것임.

추상화를 볼 때도 왜 이렇게 추상화를 했는가?
를 고려하는게 중요함.


OS를 왜 배워야하나?

memset을 코드로 두번 연속하면
2번째는 이름만 다른데 시간이 훨씬 덜 듦.

캐싱 때문임.

이제 memset의 데이터 크기를
1MB에서 1GB로 하면 10배 차이의 시간이
2배 정도로 줄었음.

캐싱만 영향을 준게 아님.
demand paging도 영향을 줌.
아주 큰 크기면 접근하기 전까지 할당하지 않지만,
memset으로 두번째 접근할 때면 이미 할당해서
page fault를 겪지 않으며 시간이 줄어듦.

즉, memset은
메모리 초기화, 할당의 역할을 하지만,
정확히는 그러한 역할을 하는데에 명령할 수 있는 인터페이스일뿐,

실제로 일이 어떻게 벌어지는지 이해하는데에는
OS에 대한 이해가 필요함.
그래야 실제 동작이 왜 이렇게 일어나는지 이해할 수 있음.


OS는 무슨 필요로 탄생했나?

결국 OS는 일종의 디자인 기법임.
(하드웨어와 소프트웨어를 잇는.)

옛날에는 API를 짜면 자연스레 하드웨어 접근 I/O도 짜야했음.
그렇지만 디바이스 접근 방식은 대개 공통적이었음.

그래서 하드웨어에 쉽게 접근 가능한,
공통적인 API를 짜볼까?

라는 게 OS 탄생 계기임.

OS의 중요 목적 세가지는 이러함.

  • abstrctions.
    모두가 이해하고 사용할 수 있게 어떻게 추상화할 수있는가?
  • Protection & Isolation
    임의의 App에게서 데이터를 보호할 수 있는가?
  • Sharing
    CPU, DISK, Memory 간의 데이터 분배를 어떻게 할 것인가?

abstraction?

프로세스나 결과를

  • 이해하기 쉽고
  • 이해하기 쉽도록, 중요하지 않은 일부 디테일을 생략

하는 과정.

사람은 추상화 시켜서 기억하기 때문.

모.. 유명... 이름까먹었다 분은
OS의 가장 중요한 점은 problem decomposition이라고 함.
문제를 쪼개는 것인데, 한번 생각해보라.

문제의 크기가 커질 수록?
복잡도는 높아진다.
어떻게 높아지냐면 지수적으로 높아질것이다.

복잡도가 높아질수록 처리하기 까다로워진다.
그래서 복잡도를 낮추기 위해,
문제의 크기를 줄이는 게 중요하다.

따라서 OS 디자이너가 고려해야하는 건...

  • 프로그램에게 간단해야한다.
    아무도 하드웨어 디테일까지 손보고 싶지 않다.
  • 실행하는 유닛을 관리해야한다.
    하드웨어 리소스를 유용할 때, OS는 여러 APP을 돌릴 수 있어야한다.
  • 실행 유닛끼리 보호 관리해야한다.
    서로를 침범할 수 없어야한다.

그래서 결론은?

각 app이 single machine에서 돌아가는 것처럼
추상화를 제공해야한다!

이를 process라 하자!

하드웨어는 어떻게 쉽게 만들지?

OS는 각 하드웨어를 추상화 시켜서
process와 연결시켜야한다...

  • CPU -> Virtualizing CPU
  • Memory -> VA space
  • Storage -> File

(사실 CPU, memory, storage라는 것 자체도
하나의 machine에서 3개로 나뉘어지는 top-down식 접근임.)

그리고 이러한 abstraction에 접근할 수 있는
API를 제공해야했는데,
그게 바로 system call이다.

process 추상화?

그래서 single 머신에 있는것처럼 추상화를 한다.

각 프로세스는 각자의
address space,
virtual CPU,
files가 있다.

그 중의 address space를 보자.

address space 예시

예를 들어,

stack
heap
data
text

순으로 address가 쌓여있을때,
이러한 코드가 있다고 생각해보자.

int c;
int b;
void func(void){
	int a;
    int c;
    c = malloc
}

이것들은 이렇게 저장된다.

stack - int a, int c
heap - c malloc
data - int b, int c
text

...
그렇다!

실제로 이것들은 어떤 식으로 이 값들을
이러한 순으로 저장을 하는 걸까?
저장을 한다는 건 무슨 과정을 거치는 걸까?

Address space 추상화

각자의 싱글 머신의 VA가
물리 메모리의 특정 영역에 mapping 된다.
그 때의 물리 메모리의 블록 단위의 호칭이 page다.

그 mapping이란 뭘까?

(PA) = f(VA)

...같은 식으로,
VA를 PA로 바꾸는데,

그 f라는 함수의 방식으로
segmentation paging,
paging,
.... 등등이 있는 거다!

그래서 추상화할때는 저러한 방법이 있다는 걸 숙지는 해야하나
저 공식으로 이루어져있다고 이해하는 게 중요하다.

또, 이러한 부분을 MMU에게 맡긴 것 또한,
중간에 해결하기때문에 memory 속도가 빠르기때문이라는 것도 알아두자!

그럼 그 방법 중의 paging을 살펴보자.

paging

paging 시 판단해야하는 건 뭘까?
어떤 조건이 중요할까?

  • 접근이 가능한가?

이다. 여기서 판가름 나서 두 가지 경우로 나뉜다.

근데 왜 이런 것을 판단 해야할까?

그건,
접근 불가 메모리가 있기 때문이다.
접근 불가인지, 불가가 아닌지 어떻게 구별하나?

page table을 참고한다.
만약 page table 내에 없으면 튕겨내는 식이다.
(애초에 내가 배정받은 page가 아닐테니까.)

이러한 page fault를 일부러 유발하기 위한
메모리에는 주소지의 0부분에
접근 불가 영역 메모리를 만들어 거기로 일부러 빠지게 하는 것도 있다.

함수 f의 방식따라(paging... segemen..)
장단점이 뭔지는 각자 알아보자.

page table ...?

page table은 어디에 저장하는가?

대개 memory다.

그러면,

page table 사용시 어디부터 어디까지가 OS의 역할이고
어디가 haredware의 역할일까?

  • OS : page table 세팅(값을 세팅.)
  • hardware : 참조해서 매핑 값 사용.

OS를 디자인하는 입장에선?
당연히 page table을 만들어야하는구나! 를 알게된다.

그럼 page table 수준에서
VA와 PA를 매핑하고
할당 가능, 불가를 쓰는 건 이미 어느 정도 알것이다.

그렇다면...

물리메모리는 언제 할당할 것인가?

OS는 물리 메모리 할당 시점을 알아야한다.
그건...

page fault가 일어나
demand paging 하는 시점이다.

실행파일 -> page fault -> page fault handler -> PA (필요하다면 zero page) -> page fault handler -> 본래 실행파일

이 과정이 일어나는, t초 동안 멈춘다.

특히 여기서,
page를 zero로 만드는 시간이 가장 오래 걸리는데,
왜 0으로 만드느냐?

protection이 목적이다.

싱글 머신끼리는 간섭하지 못하게 한다는 걸 기억하는가?
그러므로, 사실 자기 머신이 자기 정보에 접근하는건 상관이없다.

그래서, page를 0으로 만드는 과정은
다른 프로세스 데이터 접근 시에만 이뤄진다.

그렇게 물리 메모리를 할당하는데, VA에서 물리 메모리 타입이 두 가지로 나눠서 해야한다고?

물리 메모리는 타입이 두 가지로 나뉜다.

stack
heap
data
text

...
data, text는 file backed 이고,
stack, heap은 anonymous다.

전자는 자리가 없으면 disk로 빠지지만,

후자는 초기화 시 반드시 0으로 초기화할뿐더러
자리가 없으면 swap disk 부분을 이용한다!

즉,
page fault가 발생해도
어느 지점에서 발생했느냐에 따라
처리를 다르게 해줘야하는 것이다!

그래서 kernel 수준에서
두 가지를 나누어 관리한다.

page fault handling

이때,
아무튼 disk를 읽어야하는데,

방식은 DMA 형식으로 진행한다.

데이터가 도달하면,
read가 끝났다고 알리는 interrupt를 받아오는 것이다.

(그래서 DMA와 interrupt는 페어라 생각하는게 좋다.)

...

자!

그래서 process abstraction의 흐름은...

process
-> VA -> page table -> MMU(PF)
-> VA layer, PA layer -> PA manegment -> DMA, Interrupt...

...
라고,

프로세스!
VA 생성!
접근 가능한 VA임? (page table, MMU 참고)
-> PF
-> PF handler
-> file backed임? anonymous임?
-> 두 타입에 따라 따로 하되 일단 disk 읽는거니 DMA, interrupt

여기서 OS는
page table도 만들고
PF handler도 다루는거구나~ 하는...
그런...
그런 전체적 흐름을 파악하자.

profile
개발자 희망...

0개의 댓글