[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fhkmgUCNDoXlkKmwjFKErfK3pprMgfQf2KbQqCrqWcZ4":3},{"item":4,"related":44},{"id":5,"type":6,"title":7,"slug":8,"summary":9,"body":10,"coverUrl":11,"productScreenshots":12,"productLinks":13,"authorName":14,"authorUrl":15,"authorSubject":16,"category":17,"tags":22,"sourceLabel":35,"sourceName":36,"sourceUrl":37,"status":38,"seoTitle":7,"seoDescription":9,"canonicalUrl":35,"isFeatured":39,"sno":40,"sortOrder":41,"publishedAt":42,"updatedAt":43,"createdAt":43},"0bc79f1c-f305-4d64-a9f8-589d1d6da0b3","article","EEVDF：Linux 如何判断哪个任务“最该先用 CPU”？","eevdf-linux-fair-cpu-scheduling","EEVDF 是 Linux 调度器的一种公平调度思路：先判断任务是否获得了应有份额，再按虚拟截止时间安排运行机会。本文用共享厨房的比喻，解释它如何兼顾长期公平与短期响应，并澄清它并非硬实时保证。","想象一台电脑里有几十个程序都在等着使用 CPU：浏览器想响应点击，音频播放器怕断音，后台任务则希望尽快跑完。操作系统每隔很短时间就要决定“下一小段时间轮到谁”。EEVDF 是 Linux 调度器采用的一种公平调度思路，它试图同时回答两个问题：谁长期得到的 CPU 时间偏少？谁眼下最需要尽快获得一次运行机会？\n\nEEVDF 的全称是 Earliest Eligible Virtual Deadline First，可译作“最早合格虚拟截止时间优先”。它不是按现实世界的钟表给进程排一个硬期限，而是在公平份额的基础上，为任务计算虚拟时间与虚拟截止时间。虚拟时间可以理解为一把经过校准的尺：任务实际运行越多，刻度前进越快；权重较高的任务则相当于用不同速度计量。这样，调度器就能比较不同任务相对其应得份额究竟是“超前”还是“落后”。\n\n这里的“合格”很关键。若某任务此前拿到的 CPU 少于它按权重应得的份额，它就处于合格状态；一个已经明显超前的任务，不会仅仅因为自己的截止时间看起来靠前，就一直抢占别人。调度器先筛出合格任务，再在其中选择虚拟截止时间较早的任务运行。运行一段后，它会重新计算状态，做下一次选择。\n\n为什么还要有截止时间？单纯追求长期平均公平，不一定能让交互操作及时得到响应。虚拟截止时间给每个任务的运行机会排出相对次序，搭配运行片段长度等因素，能在公平与响应性之间做更细的安排。延迟敏感的工作可以申请较短的运行片段，尽早得到一次服务；这不等于它能无限占用处理器，公平性约束仍在起作用。\n\n可以把它想成共享厨房：每位厨师按约定拥有不同份额的灶台时间，系统会照顾排队较久、实际用时不足的人，同时把下一轮机会交给虚拟排期靠前者。它比“谁先来谁一直做”复杂一些，但也更能兼顾长期份额与短期响应。\n\n需要注意，EEVDF 不是实时系统中的硬截止期调度器。它不能保证某个普通应用必定在指定毫秒前完成，也不意味着所有桌面操作都会变得更快。最终体验仍受 CPU 负载、任务优先级、内核配置和程序自身行为影响。它解决的是通用调度器如何公平分配处理器时间的问题，而不是把每个任务变成有硬时限的实时任务。\n\n简而言之，EEVDF 的重点是“先看谁有资格，再看谁的虚拟截止时间更早”。这让调度器有机会在长时间公平与短时间响应之间更灵活地折中。想继续深入，可以从 Linux 内核文档对虚拟运行时间、lag 和 eligible 队列的说明入手。\n\n来源：[Linux 内核文档：EEVDF Scheduler](https:\u002F\u002Fdocs.kernel.org\u002Fscheduler\u002Fsched-eevdf.html)","\u002Fuploads\u002F2026-10-13\u002Fdc59d374-8c78-41ba-bdfe-a6f0e62ab246.jpg",[],[],"Foundit","https:\u002F\u002Ffoundit.cn","foundit-ai-editorial",{"id":18,"name":19,"slug":20,"description":21},"6179d3b6-dc34-4483-9ded-3cd9f1b37a47","科普","abbreviation","介绍各领域新兴概念",[23,27,31],{"id":24,"name":25,"slug":26},"7c76bfc2-f80f-4ee0-a95d-27bd8708b434","技术","slug",{"id":28,"name":29,"slug":30},"144abe77-0dc6-4f66-a176-20bddb1c0bfa","编程","coding",{"id":32,"name":33,"slug":34},"4c2bbea6-eab7-40a8-8447-1de478ff7749","分析","analyse",null,"Linux Kernel Documentation","https:\u002F\u002Fdocs.kernel.org\u002Fscheduler\u002Fsched-eevdf.html","published",false,43,0,"2026-10-13T00:00:00.000Z","2026-10-13T02:13:28.103Z",[45,54,62],{"id":46,"type":6,"title":47,"slug":48,"summary":49,"coverUrl":50,"authorName":14,"sno":51,"publishedAt":52,"createdAt":53},"5e0c84da-6011-41e8-b1f7-726c8bf0b30a","RCU：读多写少的系统，为什么敢让读者几乎不加锁？","rcu-read-copy-update-explained","RCU 把共享数据的更新与旧版本回收拆开，让读者以极低成本读取，同时等待所有旧读者离开后再释放内存。本文用导览图解释它的读侧、宽限期与适用边界。","\u002Fuploads\u002F2026-09-26\u002F3398ce37-ca4f-4cc3-84b3-fe931d2f055d.jpg",41,"2026-09-27T00:00:00.000Z","2026-09-26T16:25:40.784Z",{"id":55,"type":6,"title":56,"slug":57,"summary":58,"coverUrl":59,"authorName":14,"sno":60,"publishedAt":52,"createdAt":61},"23b5596a-29ab-4ff8-8237-1fd34d8e0bd1","Seqlock：读者不加锁，为什么还能读到一份一致的数据？","seqlock-sequence-counter-explained","Seqlock 让读者先后读取序列号并在变化时重试，以校验快照是否被写者打断，适合读多写少且字段可安全复制的数据。","\u002Fuploads\u002F2026-09-26\u002Fe6a9caee-7551-469f-9b16-d27fcc97f034.jpg",44,"2026-09-26T16:25:51.305Z",{"id":63,"type":6,"title":64,"slug":65,"summary":66,"coverUrl":67,"authorName":14,"sno":68,"publishedAt":52,"createdAt":69},"6ced249d-9a51-438b-b51a-8ebb9a27a949","NUMA：同一台机器上的内存，为什么有的更近更快？","numa-non-uniform-memory-access","NUMA 把多路服务器的 CPU 与内存看成多个距离不同的节点，本地访问通常更快，线程与数据的放置会直接影响吞吐和尾延迟。","\u002Fuploads\u002F2026-09-26\u002F1bf98759-c58b-4537-a274-ebc889f06f89.jpg",48,"2026-09-26T16:26:03.813Z"]