From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5189730C16B for ; Thu, 30 Jul 2026 03:18:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785381528; cv=none; b=Vu0SWqlhvVtOubaVdotMpcSkFwuqplbG/Q4FrECJsoAniqayx90clHKo2ZI80pKs6Tw2vH00artk0L+9FTlLG018RjsTpc/DCKjh4CWEIkt618PbOCdfz0lUk6rUbSUAVsbvD7KFaCWK/353qkup+g1yuC+0sE4LZmif4TK70cE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785381528; c=relaxed/simple; bh=QGsL5XcLRkG0ICs0z52lc3ouSUItS9tQwOiL5nUOCTg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=MaTlNunmmyeWE3Rc3U5rSvRcqsbCIiT6ByH0Lw99esC+jDqv4oD7J/Oqi8fGJUlVmYCnB8r3WrXKiQ/NIFR6dAx2hgN34JQhSaUyR1SBMV98zJvbDyx5pBIIPGTFwBpIFkHBdPLYODQSpT3tEz45fffzSUcj8IpKKULBXe/X5Es= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=fVDKBlfE; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fVDKBlfE" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-47f703a9e5dso742096f8f.0 for ; Wed, 29 Jul 2026 20:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785381525; x=1785986325; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=oeCxALKtqq227AX1dir59yqRYEb9BEUGkKZNdrRjOhE=; b=fVDKBlfEBq7AMrypBkAdVmfFuV3cAV0um8PPR+1m9XrvDiiq7T8wkHdRVvYXLzE/sD GSeuxJlVQcL9LmRuJqMLnOmeeefEB3LltK3ao0MJPdx0ETLG/oSCVvKBgPxtWO10YRbh ZJuzdcoACMwk4+vjCzK13GR1ZoXTGv2py6KcXsfUKohlbETL2Pd7cVh4ZdY3eRLkt99I r12+uMojU5/IsnMYCKBVwDELnq5wL7Bq1bTr+wiJ57N6CghWK/LE0k0VOK1BXZRAGf4w ZemyNODfHLAkU8RDr5WpVyibJq22OAi6PGYcnahb/nRys1bvV47y9wbz5L0pdIgzwrRA jblw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785381525; x=1785986325; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=oeCxALKtqq227AX1dir59yqRYEb9BEUGkKZNdrRjOhE=; b=jJaiODTZS7FJfTMC3rq3fHTGKs4fYE9xqmPmM2N1tXjeA/EoIGMhcMOk06BM05oU8z LI9YJWlMI7ZgDlkx4CJiuD0J8y3xlg4oxAIy7XD6m812FSDz+oYBG/tIBGagtfLmYJEH c+lj3Tw5eV2+3q9OfhgtuRuT7YxGJSeaOoIJtkdhl2273vIu8g59aHJN/auJgXf2W9Nf ofWG4VYQz7ixLt9fvWnUWaYA68HJZ2etvtF48hEpkKwBRBZXwO/Yx20LrwI6x1lrotEl nR8OU1sa1xaZnIgBC6GJHLXdPRjpVrZ4trzOxLxtmsDZ2KjEaHYPaVFaWL2GPne8Zs5R A8jg== X-Forwarded-Encrypted: i=1; AHgh+RrN8v/I96Vk9CSBqWBNJjilg8CNFI8T8uCDMD01TgPNrL3VMXLucGEtimYJrtvyrBpTbGWjalCQNSTdu7Y=@vger.kernel.org X-Gm-Message-State: AOJu0YxNdnOFFeKsWESskKLL+vpish+VkrvbpDXy+LqQUmPncmFB4lBT 4ocPDoFPgFaJ6JkEqJ6MKJe16kX7e0gTrPLfh1ayvR10iv01Ln3yVwoA X-Gm-Gg: AR+sD13aCcCpCmTbY7k4PD/lIVCp6PbT7i1pzhXHagSMIo+jB0eB5fPSOeZK1btDvj0 v5yme9DflyNTNCCnBkbelI970JQxVpULe9KCZwLtv1NKoGWRpOK1XUEHYwOTvrbHVIbyv3KJ5tG wvVJUJ9fg+qJeUtwekJCfLwfpq4iQWR557kEisms7FyBfcKOzg+1PrDhymvBHpqRApiTht8+KG1 czeg/yuvM8aRLJMQvxN+Dkib6LVX+EDCdlCsKuLO5EpmaogoTqU8Zi/g9Xlo8VDVlBNpDryuUyV s9IHerV94u3Xy38qeNB4FNO2CWcvyQa7Wf4ue1JqIWQdvklKET/TVRocBiNuhYop3+HlWKqidbg hwPXhIO7+vxy4/et5J2ov2fV38oJkG3wYwQDpiqRGRPUxgnPheijBFrkR3NhbO++igRb4hTVx0v 9M6oi67KRNg/w26KNokLbf5FbmiVGxRpkDqfWOun/l0KUmyGgO40GLgYM0XgURNZbf2QUWPsb05 8Ke X-Received: by 2002:a05:600c:1553:b0:497:ff4c:246 with SMTP id 5b1f17b1804b1-49800e8666dmr8659875e9.16.1785381525528; Wed, 29 Jul 2026 20:18:45 -0700 (PDT) Received: from osman.mioffice.cn ([43.224.245.178]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fc893fe58sm3015590f8f.31.2026.07.29.20.18.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jul 2026 20:18:44 -0700 (PDT) From: Zhan Xusheng To: Jonathan Corbet , Ingo Molnar , Peter Zijlstra Cc: Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Shuah Khan , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Zhan Xusheng Subject: [PATCH] docs/scheduler: fix EEVDF-related inaccuracies in the scheduler docs Date: Thu, 30 Jul 2026 11:18:33 +0800 Message-ID: <20260730031833.2228115-1-zhanxusheng1024@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Zhan Xusheng While checking the scheduler documentation against the current code I found a few inaccuracies: - sched-design-CFS.rst still describes the fair class as always running the smallest-vruntime ("leftmost") task and references the rq->cfs.min_vruntime field. Since commit 147f3efaa241 ("sched/fair: Implement an EEVDF-like scheduling policy") in Linux 6.6 the fair class implements EEVDF -- pick_eevdf() selects the eligible task (lag >= 0) with the earliest virtual deadline -- and the runqueue's zero-lag reference is now cfs_rq->zero_vruntime (the min_vruntime field is gone). Add a note that sections 2 and 3 describe the original CFS design and no longer match the code, rather than rewriting the historical text. - sched-eevdf.rst said Linux 6.6 was released in 2024 (it was 2023) and described the per-task slice request as "the new sched_setattr() system call". sched_setattr() has existed since Linux 3.14; the slice is carried in the sched_attr::sched_runtime field. Fix both. No code changes. Signed-off-by: Zhan Xusheng --- Documentation/scheduler/sched-design-CFS.rst | 10 ++++++++++ Documentation/scheduler/sched-eevdf.rst | 7 ++++--- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/Documentation/scheduler/sched-design-CFS.rst b/Documentation/scheduler/sched-design-CFS.rst index 03998f6c8f9c..55163506407b 100644 --- a/Documentation/scheduler/sched-design-CFS.rst +++ b/Documentation/scheduler/sched-design-CFS.rst @@ -15,6 +15,16 @@ scheduler's SCHED_OTHER interactivity code. Nowadays, CFS is making room for EEVDF, for which documentation can be found in Documentation/scheduler/sched-eevdf.rst. +.. note:: + + Since Linux 6.6 the fair scheduling class implements EEVDF rather than + the original CFS algorithm. The task selection and placement described + in sections 2 and 3 below (running the smallest-vruntime / "leftmost" + task, and the ``rq->cfs.min_vruntime`` field) describe the original CFS + design and no longer match the code: EEVDF picks the *eligible* task + with the earliest virtual deadline, and the runqueue's zero-lag + reference is now tracked in ``cfs_rq->zero_vruntime``. + 80% of CFS's design can be summed up in a single sentence: CFS basically models an "ideal, precise multi-tasking CPU" on real hardware. diff --git a/Documentation/scheduler/sched-eevdf.rst b/Documentation/scheduler/sched-eevdf.rst index 83efe7c0a30d..e3d62de004c6 100644 --- a/Documentation/scheduler/sched-eevdf.rst +++ b/Documentation/scheduler/sched-eevdf.rst @@ -4,7 +4,7 @@ EEVDF Scheduler The "Earliest Eligible Virtual Deadline First" (EEVDF) was first introduced in a scientific publication in 1995 [1]. The Linux kernel began -transitioning to EEVDF in version 6.6 (as a new option in 2024), moving +transitioning to EEVDF in version 6.6 (released in 2023), moving away from the earlier Completely Fair Scheduler (CFS) in favor of a version of EEVDF proposed by Peter Zijlstra in 2023 [2-4]. More information regarding CFS can be found in @@ -28,8 +28,9 @@ by sleeping briefly to reset their negative lag: when a task sleeps, it remains on the run queue but marked for "deferred dequeue," allowing its lag to decay over VRT. Hence, long-sleeping tasks eventually have their lag reset. Finally, tasks can preempt others if their VD is earlier, and tasks -can request specific time slices using the new sched_setattr() system call, -which further facilitates the job of latency-sensitive applications. +can request specific time slices via the ``sched_runtime`` field of the +sched_setattr() system call, which further facilitates the job of +latency-sensitive applications. REFERENCES ========== -- 2.43.0