<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Scheduling on Hammer's Blog</title><link>https://lkic1625.github.io/blog/scheduling/</link><description>Recent content in Scheduling on Hammer's Blog</description><generator>Hugo</generator><language>ko-kr</language><copyright>© 조원빈 - All rights reserved</copyright><lastBuildDate>Thu, 08 Oct 2026 17:53:40 +0900</lastBuildDate><atom:link href="https://lkic1625.github.io/blog/scheduling/index.xml" rel="self" type="application/rss+xml"/><item><title>스케줄링: 네트워크, SQS, HTTP/2</title><link>https://lkic1625.github.io/os-scheduling/</link><pubDate>Thu, 08 Oct 2026 17:53:40 +0900</pubDate><guid>https://lkic1625.github.io/os-scheduling/</guid><description>&lt;ul>
&lt;li>기본적인 다단계 피드백 큐와, lottery 알고리즘을 설명한다.&lt;/li>
&lt;li>lottery 의 좋은 점은 기존의 스케쥴링된 상태를 추적하고 표현해야 하는 것들을 단순한 ticket 및 확률론에 기대서 구현하여 구현이 단순하다는 장점이 있다.&lt;/li>
&lt;/ul>
&lt;h2 id="스케쥴링이-쓰이는-다른-분야는">스케쥴링이 쓰이는 다른 분야는?&lt;/h2>
&lt;ul>
&lt;li>&lt;a href="https://aws.amazon.com/ko/blogs/compute/building-resilient-multi-tenant-systems-with-amazon-sqs-fair-queues/">https://aws.amazon.com/ko/blogs/compute/building-resilient-multi-tenant-systems-with-amazon-sqs-fair-queues/&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web/">https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web/&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://blog.cloudflare.com/nginx-structural-enhancements-for-http-2-performance/">https://blog.cloudflare.com/nginx-structural-enhancements-for-http-2-performance/&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://tech.channel.io/kr/articles/%EA%B8%89%EC%A6%9D%ED%95%98%EB%8A%94-%ED%8A%B8%EB%9E%98%ED%94%BD-%E1%84%8B%E1%85%A1%E1%86%AB%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%8C%E1%85%A5%E1%86%A8%E1%84%8B%E1%85%B3%E1%84%85%E1%85%A9-%E1%84%8E%E1%85%A5%E1%84%85%E1%85%B5%E1%84%92%E1%85%A1%E1%84%80%E1%85%B5-%EA%B5%AC%ED%98%84%ED%8E%B8-235661b0">https://tech.channel.io/kr/articles/급증하는-트래픽-안정적으로-처리하기-구현편-235661b0&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="network-scheduling">Network Scheduling&lt;/h2>
&lt;p>네트워크 스케쥴링은 기본적으로 전송되어야 할 패킷의 전송 순서와 전송 속도를 제한하거나 폐기하는 것을 포함할 수 있다. 일반적인 Linux 송신 경로를 단순화하면 &lt;code>Application -&amp;gt; TCP/UDP + IP -&amp;gt; qdisc -&amp;gt; NIC Driver -&amp;gt; NIC의 하드웨어 TX 큐 -&amp;gt; 링크&lt;/code>로 표현할 수 있다. 여기서 qdisc는 &lt;strong>하드웨어 큐와 별개의 소프트웨어 스케쥴링 계층&lt;/strong>이다. 이 경로는 송신 측의 개략도이며, 모든 네트워크 장치의 송수신 경로가 동일하다는 의미는 아니다.&lt;/p></description></item><item><title>LDE와 런타임 스케줄링: Go, Rust, Java</title><link>https://lkic1625.github.io/os-limited-direct-execution/</link><pubDate>Mon, 05 Oct 2026 17:22:05 +0900</pubDate><guid>https://lkic1625.github.io/os-limited-direct-execution/</guid><description>&lt;h2 id="개요">개요&lt;/h2>
&lt;p>OS에게 안전한 처리를 맡기고, 적절히 제공하기 위해 우리는 커널과 유저모드를 나누었다. 특히, 적절한 스케쥴링과 함께라면 우리는 OS로 하여금 좋은 퍼포먼스를 제공 받을 수 있을 것이다. 다만, 요즘의 프로그래밍 언어들은 여기에서 멈추지 않는다.
특히, 경량 스레드라는 모델링은 현대 시스템의 맞는 런타임 추상화를 한 번 더 진행했다. 복잡도를 늘리는 대신 OS 스레드의 스케쥴링과는 전혀 다른 영역에 런타임 스케쥴링을 하도록 하여 컨텍스트 스위칭 비용을 줄이고 효율성을 높인다. 이에 대한 간략한 추상화를 알아보자.&lt;/p></description></item><item><title>EEVDF Scheduling</title><link>https://lkic1625.github.io/eevdf-scheduling/</link><pubDate>Fri, 02 Oct 2026 11:51:54 +0900</pubDate><guid>https://lkic1625.github.io/eevdf-scheduling/</guid><description>&lt;h2 id="개요">개요&lt;/h2>
&lt;p>이건 단순 공부용 정리이다. EEVDF는 &lt;strong>Earliest Eligible Virtual Deadline First&lt;/strong>의 약자이다. 이름 그대로, 실행 자격이 있는 스레드 중에서 virtual deadline이 가장 이른 스레드를 선택한다.
&lt;a href="https://lkic1625.github.io/os-process/">4. The Process&lt;/a>에서 CPU별 rq와 cfs_rq의 내부구조를 살펴봤었다. 여기서는 그중 Fairness 수준에서 경쟁하는 스레드들을 어떤 기준으로 선택하는지 알아보자. 설명은 하나의 CPU에서 같은 작업 큐를 두고 경쟁하는 스레드들을 기준으로 단순화한다. 다만, 이는 실제 Linux에서 실행 중인 스레드의 짧은 실행 구간을 보호하는 처리 등도 있으므로, 완벽한 로직이라고 판단하면 안된다.&lt;/p></description></item></channel></rss>