프로세스 전체를 안 올려도 실행이 된다고? — 가상메모리와 요구 페이징가상메모리가 실제로 뭘 해결하는 기술인지, 요구 페이징이 어떻게 필요한 것만 골라서 올리는지, 페이지 폴트가 터지면 내부에서 정확히 무슨 일이 일어나는지, 그리고 메모리가 꽉 찼을 때 어떤 페이지를 빼낼지 정하는 알고리즘들까지 알아보자!지금까지 주소 변환, 세그멘테이션, 페이징, TLB, Multi-level Page Table을 쭉 봐왔는데, 이 모든 걸 관통하는 마지막 조각이 바로 가상메모리야. 지금까지는 "필요한 페이지는 항상 메모리에 있다"고 가정했는데, 이제 그 가정을 깰 차례야.프로세스 전체는커녕, 지금 당장 필요한 부분만 메모리에 올려놓고 나머지는 디스크에 던져놓은 채로도 프로그램이 잘 돌아가.가상메모리가 뭐야실제 물리 메..
Study/[ OS ]2026. 7. 15. 19:19
#16 Paging: Smaller Table
Page Table이 4MB라고? 이걸 어떻게 줄여 — Smaller Table지난 글에서 TLB가 관리할 수 있는 page 수보다 프로세스가 훨씬 많은 page를 요구하는 상황이 있다고 했잖아. 이럴 때 문제는 TLB만이 아니야 — Page Table 자체가 너무 커져서 메모리를 잡아먹는 문제가 따로 있어. 이걸 줄이는 방법들을 하나씩 보자.문제부터: Page Table이 왜 이렇게 커TLB가 감당할 수 있는 것보다 훨씬 많은 page를 요구하는 프로세스는 흔해. 이런 프로세스의 Page Table 크기를 실제로 계산해보자.4KB(2^12) 크기의 page랑 4바이트 크기의 Page Table Entry를 쓰는 32비트 가상 주소 공간이 있다고 하면: Page Table 크기 = (가상 주소 공간 크기..
Study/[ OS ]2026. 7. 15. 18:53
#15 변환참조버퍼 TLB _ 심화편
TLB, 실제로 얼마나 빨라지는 건데? — 숫자로 보는 TLB 심화TLB가 정확히 왜 필요한지, VPN·PFN이 실제로 어떻게 캐싱되는지, 지역성 덕분에 TLB hit rate가 왜 높아지는지, Context Switching이 왜 문제고 ASID가 어떻게 해결하는지, 그리고 TLB가 꽉 찼을 때 뭘 빼내는지까지 숫자로 직접 확인해볼게.Paging의 오버헤드, 다시 짚고 가기Paging으로 메모리를 가상화하면 메모리 접근 하나당 두 번의 작업이 필요해. Page Table에 한 번 접근하고, 거기서 얻은 정보로 실제 메모리에 또 한 번 접근하는 거야. 이 두 번째 접근이 매번 따라붙으니까 느려질 수밖에 없어. 이걸 빠르게 만들려고 나온 게 TLB야.TLB가 뭐야TLB는 MMU의 일부분이자, 주소 변환을 ..
Study/[ OS ]2026. 7. 15. 01:47
#14 변환참조버퍼 TLB _ 기본편
매번 Page Table 뒤지면 너무 느리잖아 — TLB오늘 이 글에서는 TLB가 정확히 뭘 캐싱하는 건지, TLB 안에 뭐가 들어있는지, 그리고 TLB 하나 때문에 속도가 얼마나 차이 나는지까지. 딱 기본만 다루고, 더 깊은 내용은 다음 글(TLB 심화)에서 이어갈게.지난 글에서 페이징의 문제로 "메모리 접근마다 Page Table을 한 번 더 읽어야 한다"는 걸 짚었잖아. 이 추가 접근을 없애려고 나온 게 TLB야.TLB가 뭐야Translation Lookaside Buffer의 약자야. 번역하면 변환참조버퍼, 변환우선참조버퍼, 변환색인버퍼 이렇게도 불리는데 다 같은 걸 가리켜. 한마디로 정리하면, Page Table을 캐싱해두는 저장 장치야. CPU 캐시가 메모리 접근을 빠르게 해주는 것처럼, TL..
Study/[ OS ]2026. 7. 15. 01:33
#13 페이징 (Paging)
프로세스를 16바이트씩 잘라서 아무데나 흩뿌린다고? — 페이징지난 글에서 세그멘테이션이 외부 단편화라는 숙제를 남겼다고 했잖아. 그 숙제를 푸는 방법이 페이징이라고 했던 것까지 기억해? 아이디어는 단순해 — 세그먼트처럼 가변 크기로 나누지 말고, 아예 처음부터 똑같은 크기로 잘라버리자는 거야.페이징이 뭐야Paging은 프로세스의 가상 주소 공간을 고정 크기(fixed-size)로 잘라서 메모리에 할당하는 방식이야. 이 고정 크기 단위를 가상 주소 공간에서는 page라고 부르고, 이 page가 실제 메모리에 할당되는 자리를 page frame이라고 불러. 정리하면, 가상 쪽에서는 page, 물리 쪽에서는 frame — 이름만 다르지 크기는 완전히 똑같아.페이징의 장점유연성(Flexibility)주소 공간을..
Study/[ OS ]2026. 7. 15. 01:11
#12 Segmentation
힙이랑 스택 사이, 그 텅 빈 공간은 왜 낭비될까 — 세그멘테이션base·bound 방식 하나로는 왜 메모리가 낭비되는지, 세그멘테이션이 그 문제를 어떻게 푸는지, 그리고 세그먼트별로 주소를 어떻게 변환하는지, 마지막으로 세그멘테이션이 낳는 새로운 문제(외부 단편화)까지 이 글로 같이 공부해보자!기존 방식이 왜 비효율적일까지난 글에서 본 base·bound 방식은 가상 주소 공간 전체를 물리 메모리에 통째로 하나의 덩어리로 배치했어. 근데 프로세스의 주소 공간을 들여다보면 Code, Heap은 아래쪽에 있고 Stack은 위쪽에 있고, 그 사이는 텅 비어있잖아. 이 방식은 이 텅 빈 부분까지도 물리 메모리에 자리를 잡아버려. 문제가 세 가지 생겨.안 쓰는 공간까지 자리를 차지하니까 메모리가 낭비돼주소 공간..
Study/[ OS ]2026. 7. 15. 00:01
#11 주소 변환(Address Translation)
가상 주소는 어떻게 물리 주소가 되는 거야? — 주소 변환의 시작메모리를 가상화한다는 건 결국 OS가 프로세스한테 "너만의 메모리 공간이 있어"라고 착각시키는 거였잖아. 근데 이 착각을 실제로 만들어내려면, 프로세스가 쓰는 가상 주소를 진짜 물리 메모리 주소로 바꿔주는 하드웨어 장치가 필요해. 그게 오늘 다룰 주소 변환이야.왜 하필 이런 방식으로 가상화할까메모리 가상화는 효율성(Efficiency), 제어성(Controllability), 유연성(Flexibility) 세 가지를 다 잡아야 해. 그래서 CPU 스케줄링에서 이미 나왔던 LDE(Limited Direct Execution)랑 비슷한 전략을 써.LDE를 짧게 복습하면, 프로그램을 하드웨어에서 직접 돌리다가 디스크 I/O를 요청하거나 더 많은 ..
Study/[ OS ]2026. 7. 6. 18:41
#10 주소 공간과 가상 메모리
주소 공간과 가상 메모리 — 프로세스는 메모리를 어떻게 보고 있어?메모리 계층 파트에서 RAM이 뭔지 다뤘어. 이번엔 그 RAM을 여러 프로세스가 어떻게 나눠 쓰는지, 그리고 프로세스가 메모리를 어떻게 바라보는지를 파보자. 가상 메모리는 OS에서 제일 중요한 개념 중 하나야.초기 컴퓨터의 메모리 — 한 번에 하나만컴퓨터가 처음 나왔을 때는 메모리 구조가 단순했어.OS가 메모리 앞부분을 쓰고, 나머지 공간에 프로그램 하나가 통째로 올라가는 구조야. 문제가 명확해 — 한 번에 프로그램 하나만 실행할 수 있어. 비싼 하드웨어인데 활용률이 낮아.멀티프로그래밍 — 여러 프로그램을 메모리에그래서 여러 프로세스를 동시에 메모리에 올리는 방식이 등장했어.Process A, B, C가 동시에 물리 메모리에 올라가 있어...
Study/[ OS ]2026. 7. 6. 17:35
#09 교착상태 (DeadLock)
서로 눈치만 보다 아무도 못 가는 상황동기화 글에서 뮤텍스 unlock()을 빠뜨리면 교착상태가 생긴다고 했는데, 이번엔 그게 정확히 뭔지 파보자.이미지를 보면 직관적으로 이해돼. 네 방향에서 차가 동시에 교차로에 진입해서 서로 앞을 막아버린 상황이야. 아무도 양보하지 않으면 영원히 못 빠져나와. 이게 교착상태야.교착상태란?두 개 이상의 프로세스가 서로 상대방이 가진 자원을 기다리며 무한히 대기하는 상태야. (출처: 공룡책 Silberschatz, 10th Edition)동기화 글에서 봤던 뮤텍스를 예시로 보자.// Thread 1mutex1.lock();mutex2.lock(); // Thread 2가 mutex2를 잡고 있어서 대기// ...// Thread 2mutex2.lock();mutex1.l..
Study/[ OS ]2026. 7. 2. 18:23
#08 동기화(뮤텍스, 세마포어, 스핀락)
동기화 — 공유 데이터를 동시에 건드리면 무슨 일이 생겨?프로세스/스레드 파트에서 "멀티스레드는 동기화 문제를 주의해야 한다"고 짧게 언급하고 넘어갔는데, 이번엔 그게 정확히 뭔지 파보자. 결론부터 말하면 — 같은 데이터를 여러 곳에서 동시에 수정하려 할 때 타이밍에 따라 결과가 달라지는 문제야.데이터 접근의 기본 구조컴퓨터에서 데이터를 처리하는 구조는 단순해.데이터를 읽기만 하면 아무 문제 없어. 문제는 연산하고 수정할 때 생겨. 누가 먼저 읽어갔냐에 따라 결과가 달라질 수 있거든.CPU 레벨에서 Count++ 하나도 사실 세 단계야.load X, reg1 // 메모리에서 값 읽어옴inc reg1 // 레지스터에서 +1 연산store X, reg1 // 결과를 메모리에 저장이..
