[IT] CS 면접 대비 OS 질문 모음

 

Operating System

 

 

< System Call 이란? >

 

system call 은 사용자 process 내에서 os 에 해당하는 메모리 영역에 접근(커널 함수 호출)하는 것을 말 함.

왜 접근할까? 사용자 process 가 사용 권한이 없는 함수를 호출했기 때문에 os 커널 함수에 접근하는 것임

 

예를 들어, 사용자 process 에서 파일 io 가 발생하게 되면(사용자 process 가 io device 를 사용하는 함수를 실행함)
process 는 io 디바이스에 접근 권한이 없기 때문에 os 에게 cpu 를 넘겨줌.
이렇게 사용자 process 가 커널에 접근하는 것을 system call 이라고 함.

사용자 process 는 파일에 직접 접근할 권한이 없기 때문에 커널에 (System Call을 이용하여) 파일 IO 를 대신 요청함

 

여기서 사용자 process 란, 운영체제가 실행한 process 가 아닌 사용자가 직접 실행한 process 를 말함

 

 

< Interrupt 란? >

 

'CPU의 정상적인 프로그램 실행 방해'를 의미함
프로세스가 CPU를 이용하여 한참 실행되고 있는 와중에, 예상치 못한 상황이 발생할 경우 (인터럽트가 걸림)

현재 실행중인 프로세스 작업을 잠시 중단하고 발생된 상황을 처리함

이렇게 인터럽트가 걸리면 프로세스가 점유하던 CPU 는 OS 가 가져가게 됨(상황 처리를 위해)

상황이 처리된 후 다시 원래 실행중이던 프로세스 작업으로 복귀함

 

System call 을 이용해 프로세스 자신이 직접 os 에 CPU 를 반납하는 software interrupt를 trap 이라고 함

(프로세스에서 파일 IO 를 한다거나, exception 이 났을 때 trap 이 걸림)

 

os 코드 내에 다양한 interrupt 를 어떻게 처리해야 하는지 이미 적혀 있음.
예를 들어 trap 이 걸렸을 때, 키보드 input 이 들어왔을 때, timer interrupt 가 걸렸을 때
다양한 interrupt 를 알맞게 처리할 수 있는 커널 함수를 interrupt 처리 루틴이라고 함

다양한 interrupt 와 그에 맞는 알맞은 interrupt 처리 루틴을 매칭해 둔 테이블을 interrupt vector 라고 함

즉, interrupt 가 들어오면, interrupt vector 를 확인하여 알맞은 interrupt 처리 루틴(함수)를 동작시켜 interrupt 를 처리하게 됨

 

프로세스가 "자신이 자발적으로 CPU 를 반납하는 상황"을 비선점 nonpreemptive 라고 하고,

"CPU 를 반납하고 싶지 않지만 강제로 빼앗기는 상황"을 선점 preemptive 라고 함.

 

 

 

 

< 32비트 64비트 운영체제 차이 >

 

32비트, 64비트는 CPU ‘레지스터’의 크기
레지스터 크기가 클수록 한 번에 처리할 수 있는 정보의 양이 많아지며 그에 따라 처리가 빨라짐

또한 32bit 는 최대 메모리를 4gb 까지만 사용 가능하지만64bit 는 최대 메모리를 (이론상) 16엑사바이트까지 사용 가능

32bit 에서는 2의 32제곱(4gb) 만큼 표현이 가능하기 때문에 프로세스는 최대 4gb 메모리까지만 사용 가능

64bit 에서는 2의 64제곱(16eb) 만큼 표현이 가능하기 때문에 (이론상) 프로세스는 최대 16eb 메모리까지만 사용 가능

64bit 윈도우의 경우 최대 2TB 메모리 까지 사용 가능하다고 함

 

프로세스에 메모리가 할당되어도 사용자가 그 메모리를 모두 사용 가능한 것은 아님

할당된 메모리도 용도에 맞게 파티션으로 나뉨

유저 모드 파티션, 접근 금지 파티션, 커널 모드 파티션 등으로 나뉘며

사용자가 사용할 수 있는 파티션은 '유저 모드 파티션'

 

참고 https://arhemian.tistory.com/183

 

 

 

< Process 란? >

 

Process 란, 실행 중인 프로그램을 의미함

실제로 물리 메모리 위에 코드가 올라와서 실행 동작중인 프로그램임

 

 

프로세스는 OS 로부터 시스템 자원인 '메모리'를 할당받음

프로세스는 할당 받은 메모리를 4가지 영역으로 구분하여 사용함

• Code : 프로그램을 실행하는 코드가 올라가는 영역
• Data : static, 전역 변수 등이 올라가는 영역
• Stack : 지역 변수 등이 올라가는 영역
• Heap : 객체 인스턴스가 올라가는 영역

프로세스는 최소 1개의 스레드(메인 스레드)를 가지고 있음
각 프로세스는 별도의 주소 공간에서 실행되며, 한 프로세스는 다른 프로세스의 변수나 자료구조에 접근할 수 없음.

왜냐하면 각 프로세스 별 메모리가 독립되어있으니까
한 프로세스가 다른 프로세스의 자원에 접근하려면 프로세스 간의 통신(IPC)을 사용해야 함

 

프로세스는 크게 3 가지 상태를 갖음

- Running : 현재 CPU 를 잡고 명령을 수행중인 상태

   user mode 로 동작중일 때 뿐 아니라 커널 mode 로 동작중일 때 역시 running 상태.

- Ready : CPU 를 기다리는 상태. CPU 만 잡으면 바로 명령 수행이 가능함.

   즉, io waiting 이나 메모리에 코드 올리는 기타 작업들을 이미 모두 마쳐둔 상태.

- Blocked( wait, sleep ) : CPU 를 주어도 명령 수행을 할 수 없는 상태.

   io 응답/이벤트 응답을 기다리고 있거나,

   메모리에 실행 코드가 바뀌어 올라오고 있을 때(기존 것을 버리고 새로 실행할 코드를 올릴 때) 등

 

프로세스를 생성할 때는, 하나의 프로세스를 복제하여 생성함. 복제당하는 프로세스를 부모, 복제된 프로세스를 자식이라고 함

부모 프로세스가 갖는 것은 memory 주소 공간(code, data, stack), os 의 데이터(pcb, 자원 등), context(pc) 등.

자식 프로세스를 생성할 때, 부모가 갖고 있는 위의 것들을 모두 복사함(pid는 제외).

그 후에 자식 프로세스 위에 새로운 프로그램을 덮어 씌워서 새로운 작업을 하도록 함.

 

여기서 부모 프로세스를 복사하는 system call 이 fork() 이고

자식 프로세스 위에 새로운 프로그램을 덮어 씌우는 것이 exec() 이다.

 

자식 프로세스는 무조건 부모 프로세스보다 먼저 죽음

자식이 살아있는데 부모가 종료(exit)되는 경우, 자식들(모든 후손들)이 줄줄이 종료됨

 

프로세스는 크게 Fetch, Decode, Exetue, Update 의 4단계로 동작함
명령어를 디스크로부터 메모리로 옮기고 읽고 해석한 뒤에 알맞은 일을 수행하고 다시 다음 명령어 수행 반복

 

 

< Thread 란? >

 

쓰레드란 프로세스 내에서 실행되는 여러 흐름의 단위임

process 내부에서 똑같은 code 를 가지고 동시에 여러 작업을 하기 위해, pc(program counter) 를 여러개 둠.

 

 

쓰레드들은 프로세스의 Code, Data, Heap 영역은 공유함

쓰레드들은 프로세스의 Stack 영역은 공유하지 않고, 쓰레드 각자 고유의 Stack 영역을 갖음

(공유하지 않는 것 중에는 CPU 에 저장되는 thread 들의 pc 와 레지스터값들도 포함됨)
한 쓰레드가 프로세스 자원을 변경하면, 다른 쓰레드(sibling thread)도 그 변경 결과를 곧바로 볼 수 있음

 

추후 process context switching 이 일어날 때도,

os 는 pcb 내에, thread 에서 사용하는 pc 와 각 레지스터 값들을 여러개 저장하여

복구했을 때 thread 들 역시 정상적으로 복구되도록 함

 

< 멀티 프로세스 vs 멀티 쓰레드 >

 

멀티 프로세싱이란, 하나의 응용 프로그램을 여러 개의 프로세스로 구성하여

각 프로세스가 하나의 작업(태스크)을 처리하도록 하는 것

멀티 프로세싱 장점
- 여러 개의 자식 프로세스 중 하나에 문제가 발생하여 죽어도, 다른 프로세스에는 영향이 없음

 

멀티 프로세싱 단점
- Context Switching 오버헤드
  Context Switching 과정에서 캐시 메모리 초기화 등의 무거운 작업이 진행되어 오버헤드가 큼

- 프로세스 사이의 통신(IPC) 오버헤드
  프로세스는 각각의 독립된 메모리 영역을 할당받았기 때문에

  하나의 프로그램에 속하는 프로세스들 사이의 변수를 공유할 수 없음

  따라서 프로세스 간 통신을 위해 IPC 라는 방법을 사용해야 하고, 이것은 오버헤드를 불러 일으킴

 

멀티 쓰레딩이란, 하나의 응용프로그램을 여러 개의 스레드로 구성하고 

각 스레드가 각각의 작업을 처리하도록 하는 것

 

멀티 쓰레딩 장점

- 프로세스 내의 Stack 영역을 제외한 모든 메모리를 모든 쓰레드가 공유하기 때문에

  쓰레드 간 통신의 부담이 적어 프로그램 실행 시간을 단축함

  또한 쓰레드 간 데이터를 주고 받는 것이 간단해져서 시스템 자원 소모를 줄임

- 동일한 일을 수행하는 multi thread 가 협력하여 병렬성이 올라가고 높은 처리율과 성능 향상을 얻음

- 응답성이 빠름

  하나의 thread 가 blocked(waiting) 상태인 동안에 다른 thread 가 실행되어 처리를 빠르게 할 수 있음.
- 자원 공유를 통해 자원을 아낌
  별도의 process 를 만들지 않아도 되어 메모리를 아낌.
  만약 thread 대신 process 를 하나 더 만든다면, 별도의 메모리 주소 공간이 낭비 될 것임.
  thread 를 둠으로써 code, data, 그리고 메모리 등의 자원을 공유함. 경제적임.
- process 는 생성하거나 context switching 을 하는 비용이 비싸지만
  thread 는 생성하는 비용도 저렴하고 thread context switching 비용도 저렴함

 

멀티 쓰레딩 단점
- 주의 깊은 설계가 필요함
- 디버깅이 까다로움
- 바깥의 다른 프로세스에서 프로세스 내부의 스레드를 제어할 수 없음

  (프로세스 밖에서 스레드 각각을 제어할 수 없음)
- 멀티 스레드의 경우 자원 공유의 문제 발생 가능(동기화 문제)
- 하나의 스레드에 문제가 발생하면 전체 프로세스가 영향을 받음

 

< Context Switching 이란? >

 

멀티프로세스 환경에서 CPU가 어떤 프로세스를 실행하고 있다고 하자.

인터럽트 요청에 의해 다음 우선 순위의 프로세스가 실행되어야 됨

그러면 기존에 실행중이던 프로세스의 상태 또는 레지스터 값(Context)을 저장하고

다음 우선 순위의 프로세스 상태 또는 레지스터 값(Context)를 올려서

CPU 가 다음 우선 순위의 프로세스를 실행하도록 만듦

이 작업을 Context Switching 이라고 함

 

여기서 말하는 Process 의 Context 란, 현재 실행중인 process 가 어떤 상태에 있고
어디까지 실행했는지 등을 나타내는 프로세스 정보임.

 

process는 메모리에 개인 주소 공간을 갖고 있고 이곳에 코드(기계어)를 올림.
CPU 내에 있는 pc(program counter) 가 process 의 실행 코드(기계어) 어느 부분을 가리키는데,
pc 가 가리키는 부분에서 코드(기계어)를 읽어서 CPU 안의 레지스터에 저장한 후 ALU(산술 논리 연산장치)에서 처리함.
그 결과를 레지스터에 다시 저장하거나 혹은 메모리에 다시 저장함.

따라서 현재 process 가 어디까지 실행했는지 알기 위해(실행을 이어나가기 위해),
pc 가 어디를 가리키는지, 프로세스 메모리 주소 공간에는 어떤 코드와 어떤 함수, 어떤 데이터를 올려두었는지
CPU 레지스터에는 어떤 값을 저장하고 있는가 등을 알아야 함.
이렇게 process 의 현재 상태를 나타내는 정보를 process context 라고 함.

 

context 는 아래 세가지로 나타낼 수 있음
1. CPU 수행 상태를 나타내는 하드웨어 문맥

  - CPU 내의 PC(program counter)
  - CPU 내의 각종 레지스터들
2. 프로세스의 주소 공간
  - code, data, stack 으로 나타내어지는 프로세스의 메모리 공간들
3. 프로세스 관련 커널 자료 구조
  - PCB(Process Control Block) : process 를 관리하기 위해 os 가 갖고 있는 자료구조
    os 의 메모리 주소공간 data 영역에 process 별로 하나씩 갖고 있음.
    어떤 process 에게 메모리를 얼마나 줘야 할지, cpu는 얼마나 줘야 하는지 등을 관리

    각 process를 관리하기 위해 process 당 유지하는 정보가 PCB 에 저장됨.
  - Kernel Stack : process 가 system call 을 했을 때 실행되는 os 함수의 stack 영역.

 

 

Context Switching 을 하기 위해 기존 process A 의 정보들(CPU의 pc, memory 위치 정보, CPU의 레지스터 값 등)을
os 가 data 영역 내에서 관리하는 pcb 에, process A 를 위한 자리에 저장(백업)함.
그 후 process B 의 정보들을 cpu 와 메모리 등에 올리고 process B 를 실행. 

 

Context Switching 이 오버헤드가 큰 이유는 다음과 같음.

cpu 에는 cache memory 가 있고, 프로세서 실행시 이 cache memory 를 사용함.
context switching 이 일어나면 다른 process 를 실행하기 위해

현재 프로세서가 사용중인 cache memory 내용이 모두 flush 되어야 하는데 이것이 상당한 오버헤드가 됨

헷갈리기 쉬운 것 중 하나는,
사용자 process 가 실행중인 상태에서 하드웨어 interrupt(timer 가 아닌 interrupt) 나 system call 등에 의해
cpu 를 os 에게 넘기는 것은 context switching 이 아니라고 함.
왜냐면 os 가 일을 처리한 후 다시 방금까지 실행중이던 process에게 cpu 를 줄 것이기 때문에.

(os가 일을 처리하느라 CPU 를 가져가는 경우에는

cache memory 를 flush 하는 작업이 없기 때문에 오버헤드가 적다고 함)

반대로 timer interrupt 나 io 요청 system call 을 하는 process 는 cpu 를 놓고
다른 process 에게 cpu 를 넘겨야 하기 때문에 context switching 이라고 부름.

 

프로세스 뿐만 아니라, 쓰레드 역시 스케줄링의 대상이기 때문에 Context Switching 이 일어남.

프로세스 쓰레드 모두 컨텍스트 스위칭을 하면 운영체제 커널에게 제어권을 넘겨줌

왜냐하면 많은 수의 프로세스, 쓰레드를 os 가 스케줄링 해야하기 때문

(kernel thread 의 경우 스케줄링을 os 에게 맡김( 이것을 Global 스케줄링 이라고 부름 )

user threads의 경우 프로세스 내부에서 스케줄링을 직접 함( 이것을 Local 스케줄링 이라고 부름 ))

 

프로세스 switching 중에는 가상 메모리 공간이 남지 않음 (메모리 내에서 사라짐)

context switch 를 할 때 프로세스 캐시에 기억되는 모든 메모리 주소는 사실상 쓸모 없어지기 때문에 메모리에서 사라짐(flush)

쓰레드 switching 중에는 가상 메모리 공간이 동일하게 남음 (프로세스 내의 메모리 공간이 유지됨)

또한 프로세스 스위칭보다 Thread 의 스위칭이 훨씬 빠른데

이유는 쓰레드가 (Context Switching 을 하면) 타 쓰레드들과 공유하지 않는 Stack 영역만 처리하기 때문

context 를 백업하고 복구하는 정보량이 process 에 비해 적기 때문에 훨씬 빠르고 비용도 저렴함

 

 

< IPC 란? >

 

 

위 그림처럼 우리가 사용하는 프로세스들은 모두 유저공간(user-space, user-mode)에서 

개별로 OS로부터 할당받은 독립된 공간에서 실행됨
이처럼 프로세스는 독립된 공간에서 운행되다보니 프로세스 간에 통신이 어려움
이를 해결하고자 IPC(Inter-Process Communication)라는 프로세스들 간 통신 기술이 사용됨

 

왼쪽이 message passing, 오른쪽이&amp;amp;amp;amp;nbsp;shared memory

 

크게 두 가지 방법으로 통신

message passing

  프로세스 끼리 메세지를 주고받으면서 서로 영향을 끼치는 것.
  프로세스끼리 메세지를 주고 받을 수 없으므로, 커널이 중간에서 메세지를 전달해 줌.

shaed memory

  일부 메모리 공간을 두 process 가 공유함.
  원칙적으로 process 들은 자기 자신의 메모리 공간만 볼 수 있지만, shared memory 를 사용하여
  두 process 가 똑같은 메모리 공간(즉, 똑같은 값/데이터/코드)을 볼 수 있고 공유할 수 있게 함.

  process 들이 자발적으로 shared memory 공간을 만들 순 없음
  kernel 에게 process A와 B 가 공유 가능한 shared memory 공간을 만들어달라고 요청하면 커널이 해당 공간을 만들어 줌

 

< Critical Session 이란? >

 

동일한 자원을 동시에 접근하는 작업을 실행하는 코드 영역을 의미함

아래 예에서 P1 의 X=X+1, P2 의 X=X-1 코드 영역이 바로 Critical Session

 

 

여러 프로세스들이 동시에 공유 자원에 접근하는 것을 막기 위해

Critical Section 에 진입하는 프로세스는 공유 자원에 대해 Lock 을 획득함

공유 자원이 Lock 에 걸렸기 때문에 다른 프로세스들이 접근하거나 업데이트하지 못 함

(이를 상호 배제 Mutual Exclusion 라고 부름. Critical Session 에는 단 하나의 프로세스만 접근 가능함을 의미)

Lock 을 걸어둔 프로세스가 Critical Section 을 빠져나올 때 Lock 을 해제함

 

critical section 에 들어가기 위해 lock 이 풀리길 기다리는 Process 들이
모두 While 문에서 busy waiting 을 하며 기다리는 문제가 생길 수 있음. 이를 spin lock 이라고 함

spin lock 을 해결하기 위해, lock 이 풀리길 기다리는 Process 들을 아예 block 상태로 만들어버리는

block & wake up (sleep lock) 방법을 사용함.

< Starvation 이란? >

 

어떤 프로세스가 자원을 얻기 위해 무한정 기다리는 것.

데드락에 걸린 경우 starvation 문제가 나타남.

데드락을 방지하는 방법은 다음과 같음
- 공유 데이터(resource) 를 얻는 순서를 정함
  예를 들어 a,b,c resource 들을 모두 얻어야 실행이 가능하다면,

  반드시 a - b - c 순서로 resource 를 얻게 만듦.
- critical section 의 실행을 atomic 하게 만듦
  여러 공유 데이터(resource) 를 얻어 업데이트 하는 Critical Session 을 실행하는 와중에

  interrupt 가 걸리면 데드락이 생길 수 있기 때문에,
  Critical Session 실행 중간에 interrupt 가 걸리지 않는 것이 보장되도록 만듦

 

< Race Condition 이란? >

 

여러 프로세스들이 동시에 동일한 공유 데이터를 접근하여 업데이트 하는 상황

데이터는 마지막에 업데이트를 진행한 프로세스에 의해 값이 결정됨.

즉, 그 전에 실행된 프로세스들의 영향력이 사라지게 되어 일관성이 깨짐

 

< Round Robin 스케줄링이란? >

 

Round Robin 은 CPU 를 기다리는 많은 프로세스들에게 CPU 를 줄 때

특정 시간 만큼만 쓸 수 있도록 제한 시간을 둠

제한 시간이 끝나면 (job 이 끝나지 않았음에도) CPU 를 강제로 빼앗음(preemptive)

process 들이 CPU 를 최초로 얻기까지 걸리는 시간인 '응답시간 response time' 이 빨라짐.
왜냐면 프로세스들에게 CPU 를 조금씩 줬다 빼앗었다 하기 때문
CPU 를 나눠주는 기준은, 모든 Process 에게 균등하게 줌

 

Round Robin 외에 다른 스케줄러들이 있음

 

FCFS 스케줄링 (First Come First Serve Scheduling) : 먼저 온 것부터 처리함
SJF 스케줄링 (Shortest Job First Scheduling) : CPU 점유 시간이 짧은 것 부터 처리함
SRTF 스케줄링 (Shortest Remaining Time First Scheduling) : CPU 점유 시간이 짧은 것부터 처리함. 중간에 우선순위가 바뀔 수 있음
우선순위 스케줄링 (Priority Scheduling) : 우선순위가 높은 것부터 처리함

 

 

< I-node 란? >

 

리눅스는 파일이나 디렉터리를 생성할 때 I-node 라는 번호를 임의로 부여함.

이 I-node 를 기준으로 파일, 디렉터리를 관리

 

I-node는 리눅스/유닉스 파일 시스템에서 사용하는 자료구조를 의미함.

I-node 에는 해당 파일의 소유권, 허가권, 파일 종류, 그리고 실제 데이터 위치(address) 값이 있음.

I-node 가 같다면, 이름이 다르더라도 실질적으로 같은 파일로 인식됨.

 

< soft link (symbolic link) >

- 원본 dir A 가 있음

- I-node 가 다른 file B를 생성한 후, B 의 내용을 A 로 가는 포인터로 만듦

- B는 A의 soft link 가 됨
- soft link 는 file , dir 을 대상으로 생성 가능

- 경로 단축 등에 사용됨

특징

- A 와 B 는 I-node 가 다르므로, 둘은 서로 다른 dir
- A 를 삭제하면 B 는 포인터(A)를 잃게되므로 B 는 아무 기능을 못하게 됨
- A 를 수정하면 A 를 가리키는 B 역시 수정된 내용을 바라봄.
- B 를 삭제한다고 해서 A 가 삭제되지 않음.
- B 를 수정하면 B가 가리키는 A 역시 수정됨

 

hard link 

- 원본 file A 가 있음

- 이름은 다르지만 I-node 가 같은 file B 를 생성

- B 는 A 의 hard link 가 됨

- hard link 는 file 을 대상으로만 생성 가능.

- 보안을 위해 사용됨

  예를 들어 중요한 A 파일을 다른 사용자와 공유해야 할 때
  원본을 주지 않고 A 파일의 hard link 인 B 를 대신 공유.

특징

- A 와 B 는 I-node 가 같으므로, 둘은 서로 같은 file

- A 를 삭제해도 B 가 I-node 를 갖고 있으므로 실질적인 파일 내용은 삭제되지 않음

- A 를 수정하면 같은 I-node 를 갖는 B 역시 수정된 내용을 바라봄.

- B 를 삭제해도 A 가 I-node 를 갖고 있으므로 실질적인 파일 내용은 삭제되지 않음

- B 를 수정하면 같은 I-node 를 갖는 A 역시 수정된 내용을 바라봄.

 

결정적인 차이점은, 

원본 A 를 삭제했을 때

soft link 는 B 가 제 기능을 못한다는 것이고 (원본 파일 자체가 사라짐)

hard link 는 B 가 제 기능을 한다는 것 (B에 의해 원본 파일이 남아있음)

 

 

 

 

< 가상 메모리란? >

 

프로그램이 실행될 때, 실행에 필요한 일부분만 메모리에 올려 사용하고 나머지는 디스크에 남김

디스크가 메모리의 보조 기억장치 역할을 함

 

가상 메모리를 구현하기 위해서는 가상주소를 물리주소로 변환하는 MMU (Memory Management Unit) 가 필요

cpu 에서 코드를 실행할 때 프로세스 메모리에 접근하려면 물리 주소와 가상 주소를 매칭해야 함

매칭해서 변환해주는 시간을 줄이는 하드웨어 장치가 바로 MMU(Memory Management Unit)

CPU는 가상 메모리를 다루고, MMU 를 통해 물리 메모리에 접근을 해서 해당 데이터를 다시 CPU에 전달

 

 

가상 메모리는 사용하여, 주어진 메모리보다 더 큰 메모리가 필요한 프로세스 실행 가능

 

Virtual address (가상 주소) 란, 프로세스가 참조하는 주소 (32bit 에서) 0~4GB
Physical address (물리 주소) 란, 실제 물리 메모리를 나타내는 주소. 0~4GB 중의 일부분만 메모리에 올라감

 

메모리를 페이지 단위로 매핑 관리하는 페이지 테이블을 통해 가상 주소를 물리 주소로 변환

 

요구 페이징(demand paging)이란?
필요한 데이터를 디스크에서 메모리에 올리는 것

필요하지 않은 데이터는 디스크에 남겨둠

 

페이지 폴트(page faults)란?
필요한 페이지가 실제 물리 메모리에 부재할 때 뜨는 인터럽트(trap)

페이지 폴트가 발생하면 운영체제가 이를 해결한 뒤 다시 동일한 명령을 수행

 

페이지 부재(Page Fault)가 발생하면 요청된 페이지를 디스크에서 메모리로 읽어와야 한다.
이때, 물리적 메모리에 빈 프레임이 존재하지 않을 수 있다.

이 경우에는 메모리에 올라와 있는 페이지 중 하나를 디스크로 쫓아내어

메모리에 빈 공간을 확보하는 작업이 필요하다.

이것을 페이지 교체(page replacement)라고 한다.

페이지 교체를 할때, 어떠한 프레임에 있는 페이지를 쫓아낼 것인지를 결정하는 알고리즘을

페이지 교체 알고리즘(replacement algorithm)이라고 한다.

(가까운 미래에 참조될 가능성이 가장 적은 페이지를 선택해서 내쫓는 것이 성능을 향상시킬 수 있는 방안이다.)

페이지 교체 알고리즘의 성능은 주어진 페이지 참조열(page reference string)에 대해 페이지 부재율을 계산함으로써 평가할 수 있다.

FIFO(First-In-First-Out) 알고리즘 : 페이지 교체시 물리적 메모리에 가장 먼저 올라온 페이지를 우선적으로 내쫓는다.
LRU(Least Recent Used) 알고리즘 : 최근에 가장 오랫동안 사용하지 않은 페이지를 교체하는 기법
LFU(Least-Frequently-Used) 알고리즘 : 페이지의 참조횟수로 교체할 페이지를 결정하는 기법.

TLB(Translation Lookaside Buffer, 페이지 정보 캐시)란?

 

TLB는 가상 메모리 주소를 물리적 주소로 변환하는 속도를 높이기 위해 사용하는 캐시로,

최근에 일어난 가상 메모리와 물리 주소의 변환 테이블을 캐싱해둠.

CPU가 가상 주소를 가지고 메모리에 접근하려고 할 때

우선은 TLB에 접근하여 가상 주소에 해당되는 물리 주소를 찾고,

만약 TLB에 매핑이 존재하지 않는다면 MMU 의 도움을 받음

 

 

 

 

< vcpu 란 >

 

가상 cpu 인데, 여기서 말하는 가상화란 각 사용자들(프로세스들)이

자기가 자원(cpu, memory) 를 모두 사용할 수 있는 환경을 제공해주는 것

 

가상 메모리란 각 프로세스가 온전히 메모리 4gb 를 다 사용할 수 있게 해주는 것

프로세스는 10개라서 총 40gb 필요한데 물리 메모리가 8gb 면 모든 프로세스에게 할당해줄 수 없음

이 때 페이징 기법을 사용하여 각 프로세스가 필요한 만큼의 메모리만 사용하면서 8gb 메모리를 효율적으로 사용

각 프로세스는 자신이 4gb 메모리를 할당받았다고 생각함

 

가상 cpu 도 마찬가지

프로세스는 10개라서 총 10개의 cpu 가 필요한데 물리 cpu 는 1개밖에 없다면 9개 프로세스는 놀아야 함

이 때 time slice 기법(타이머 인터럽트) 을 사용하여 각 프로세스가 1개의 cpu 를 

정해진 시간만큼 나눠 쓸 수 있도록 해 줌 (이렇게 나눠주는 방법이 바로 프로세스 스케줄링)

각 프로세스는 자신이 1개 cpu를 할당받았다고 생각함

 

 

 

 

+ docker 와 vm 차이

https://velog.io/@kdaeyeop/%EB%8F%84%EC%BB%A4-Docker-%EC%99%80-VM%EC%9D%98-%EC%B0%A8%EC%9D%B4

https://devlog-wjdrbs96.tistory.com/279

 

 

 

참고

https://gmlwjd9405.github.io/2018/09/14/process-vs-thread.html

https://hoony-gunputer.tistory.com/entry/Thread-Context-Switching-vs-Process-Context-Switching 

https://wayhome25.github.io/cs/2017/04/14/cs-15-2/

https://mooneegee.blogspot.com/2015/01/os-thread.html

https://hoony-gunputer.tistory.com/entry/Thread-Context-Switching-vs-Process-Context-Switching

https://www.byfuls.com/programming/read?id=63 

https://eunhyejung.github.io/os/2018/07/24/operatingsystem-study15.html

https://ahnanne.tistory.com/15