<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Process on Hammer's Blog</title><link>https://lkic1625.github.io/blog/process/</link><description>Recent content in Process on Hammer's Blog</description><generator>Hugo</generator><language>ko-kr</language><copyright>© 조원빈 - All rights reserved</copyright><lastBuildDate>Wed, 30 Sep 2026 14:10:20 +0900</lastBuildDate><atom:link href="https://lkic1625.github.io/blog/process/index.xml" rel="self" type="application/rss+xml"/><item><title>프로세스와 cgroup의 CPU 자원 관리</title><link>https://lkic1625.github.io/os-process/</link><pubDate>Wed, 30 Sep 2026 14:10:20 +0900</pubDate><guid>https://lkic1625.github.io/os-process/</guid><description>&lt;ul>
&lt;li>프로세스는 메모리에 올라가 실행되는 프로그램 흐름&lt;/li>
&lt;li>이전에 Process 라는 추상화된 개념은 각 프로그램끼리의 독립적인 흐름을 필요로 하기에 더욱이 격리될 필요가 있었음.&lt;/li>
&lt;li>다만, 근래에 와서는 프로세스는 단순히 공통 실행 흐름의 역할을 하지 실제 CPU의 적재되어 실행되는 단위라고 보기 어려움. 과거 UNIX에서 실행흐름이 아래와 같았기에 그렇게 배우는 것&lt;/li>
&lt;/ul>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#fff;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-text" data-lang="text">&lt;span style="display:flex;">&lt;span>1 Process = 1 Address Space + 1 Execution Flow
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;h3 id="현대의-virtual-thread-coroutine-까지">현대의 Virtual thread, Coroutine 까지&lt;/h3>
&lt;ul>
&lt;li>현대에 와서는 더욱 복잡하다, 특히 프로세스라는 개념보다는 Kernel Thread 로 인식된다. 특히, Linux에서는 둘 다 task 라는 개념으로 컨텍스트를 저장하기도 한다.&lt;/li>
&lt;li>하지만 여전히 멀티 스레딩의 모델이어도 현대의 시스템에서는 충분하지 못하다, 실제로도 수만개의 스레드가 특정 프로세스의 생긴다고 해도 이것이 모두 cpu 자원을 사용하는 게 아니다.&lt;/li>
&lt;li>그렇기에 커널이 모르는 새로운 실행 흐름을 만들자는 게 vitual thread, coroutine, goroutine, async/await 등이 나오게 됨&lt;/li>
&lt;/ul>
&lt;pre tabindex="0">&lt;code>Process
 └─ Runtime
 ├─ N개의 Virtual Thread
 │ ↓ multiplexing
 └─ M개의 Kernel Thread
 ↓ scheduling
 CPU
&lt;/code>&lt;/pre>&lt;ul>
&lt;li>virtual thread 는 cpu scheduling 과 독립적인 스케쥴링을 한다는 데에서 또한, 기존에 thread-per-request 모델을 확장하는 데에 있어서 중요하다. 특히 컨텍스트 스위칭의 문제라기보단 실제 커널 모드에 진입해 syscall 을 하는 과정에서 생기는 오버헤드가 크기에 이를 우회하기 위함도 있다. 물론, Carrier Thread 를 재사용한다는 측면에서 시작된 것 역시 맞다.&lt;/li>
&lt;/ul>
&lt;h2 id="cgroup-mechanisms">cgroup mechanisms&lt;/h2>
&lt;p>시분할 메커니즘은 우리에게 여러 개의 프로그램이 거의 동시에 동작하는 것처럼 보이도록하는 효과가 있다. 다만, 현대의 시스템은 이를 더더욱 활용하기 위해 확장하고 제안한다.
예를 들어보자, Docker 등의 Container Runtime 에서 Resource Limit 을 지정할 수 있고 이를 위해 vcpu, mem 를 설정해본 기억이 있을 거다. 이러한 제약은 어떻게 이루어질까? 대표적으로 알려진 이러한 자원 할당 메커니즘은 Linux 의 cgroup 이다.&lt;/p></description></item></channel></rss>