From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) (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 3167337C108 for ; Mon, 29 Jun 2026 03:02:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782702129; cv=none; b=r7vwgMkwWInXbGypMC6AGWgyeTZTceqqxag6Xi4hSSOLgCvYXoJWjqSgZp+IUmPJqe+okqN4HfE3pHWBdSRR4jrMU7A076GFTLMNP24FRkbDM76MLMnWtdbIwPYTO6N0ufObS4cXQ69QcNm+yG/5DgvDRUPeFrFDAFgZJA51CKU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782702129; c=relaxed/simple; bh=TlLDhWl0J1eotLebQ2szdX8KlGshSX1MBzPLXVC0zD8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=BpYS3Iy2RpDBiwIG2AYSQUudpSOE0w53XsxJk8kJHV0uT0r6aW6y3MrL7ElpYNiT6xV2Sp5aC3Cy+1009T+8wm99jf8PFD1ZEkm99uMmb36/ot6myHuzfKx6r+bvWsk/bJv2NSsOME+etWd5Yj/e65Rjq2vGVn+nfVXs3ywz/JQ= 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=kTtL7YzW; arc=none smtp.client-ip=209.85.215.179 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="kTtL7YzW" Received: by mail-pg1-f179.google.com with SMTP id 41be03b00d2f7-c9aea40d799so25230a12.0 for ; Sun, 28 Jun 2026 20:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782702127; x=1783306927; 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; bh=47TiUOBvZr0rFms0/1fnTpwUIKGErjp1wql3hrvmaJw=; b=kTtL7YzWrvxixPdL6VgbzNPc5G+pwoR+wbTUDBjDetYtP94ZuSwSHhUFVMpNFifE1r KJnb0zPbc+fOPDnb5ANfR3+wQeh5RipIUsKuc9NENP/g/WZB8LVXBz6HwDF8AYhBOZu2 jcNgzDAaFUriD/rUBXBXs00hfsLKjibz3P88Zi6WJOnrxs8eORKWI3RyWQmoDfvGXCcY iOw3O0Y8O4iYUX0zulH3QubU/bpSNcwq/d31qrUCEp+LW9ZV9tyN9LpWW5SSG/Z+ysSf v2BYwl57mlyL/hHjf+aytyUte3WXshaH/q+a3C/O0wv1OtUcqZnTk/5pMUKbJyuTLnUM f02Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782702127; x=1783306927; 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; bh=47TiUOBvZr0rFms0/1fnTpwUIKGErjp1wql3hrvmaJw=; b=d/pRxcLuFO+D9i11u0NRbPS9jrD87Tw0/dF5g9OI+k4nlc1bV+om+/uenBF+RsXr8t b/3Kj4F3rrTF4qMfyMXB+9Vq23evJdTVxi7T4SESbqUp6riC5JvoRnks1gvXHKtj99jw m3vM8leaj1v62NIfCCItaboW67phR/t6PEmpVmARx8ffq/7Mj4v+uOtGaClv6vQzKQSQ z6jwH16sOGxFY8gfX8f5A/kQI+kfch5yCUKd+aEtxxwtLHBX1wpONMyOAQ18WjMx4O/R wv/z/CMRHAp3ygBO03qWTDXzcFj0+Anvg6JCSRPYoL3udViG6pYysk2pSzkRTwxoBdUW utzQ== X-Forwarded-Encrypted: i=1; AFNElJ8RfotoY84h1x4RWe0gKhoBb4ZRT0wWEYHo1bX3xEjBHCbln5gwpDuZmL6DQP8uubnQ4lZzqwInu/juzJE=@vger.kernel.org X-Gm-Message-State: AOJu0Yyw+G7btvWibpnBPjSQAUSTe7VKtjsUWwnCEGLs03SgS7/3E8Wn 1/ofoQjUQu5HivnrXqaXz4IstKFhBJAj98efM17JCImzT4bCsFxoGxS9VHLPTQ== X-Gm-Gg: AfdE7cnM67j4f04QiZVdnFvpghXns2bPxX63DwbNjxw0trQu622lh/Bab8swv+cDNV4 qnohji1uCCvjry3jIX4tp3yN59Pt+tGHZQRFgMA3dApV5D2OBytJdxdKSRtablIer/1fCy4Ed8q 3vTD9FqiDmSOqZmiYByZwrc3sAlKoNKIh6sTLLoO6thAaxoa5zKS7Ps98SApqmX7tCkGEpcRz6L Uf84X3Boyb+zSA7g/bvNHck9As5nbUgKehVTNQWZAA5AwL65iv+PtocgUMh8pY+q75UWOH4duCk ZL3Hiulqhrww7jcUQDdW/xdxXSG24+/LbmyjgVw+P6O9/dBg9KNDktzRE9JwqPUecvDPL6HKMYb m+n5S4Pg9n48TJo6Dgw6FmCdJzpIhck8CVwJqOGqbsY7uUH3QjkLBr6PSsksZGHSfxBu8n782bv F5uT5aqRTkSCBnGe5kbSGXBp8= X-Received: by 2002:a05:6a21:608a:b0:3bf:8e94:697 with SMTP id adf61e73a8af0-3bf8e940b62mr2869436637.8.1782702127265; Sun, 28 Jun 2026 20:02:07 -0700 (PDT) Received: from osman.mioffice.cn ([43.224.245.178]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c93522747efsm6149075a12.22.2026.06.28.20.02.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Jun 2026 20:02:06 -0700 (PDT) From: Zhan Xusheng X-Google-Original-From: Zhan Xusheng To: Peter Zijlstra , Ingo Molnar Cc: Juri Lelli , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , K Prateek Nayak , linux-kernel@vger.kernel.org, Zhan Xusheng Subject: [PATCH] sched/fair: Fix stale comments referring to removed CFS concepts Date: Mon, 29 Jun 2026 11:02:00 +0800 Message-ID: <20260629030200.3165589-1-zhanxusheng@xiaomi.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 A few comments still describe the pre-EEVDF CFS world: - sysctl_sched_base_slice is documented as "Minimal preemption granularity for CPU-bound tasks". That was the wording of the old sysctl_sched_min_granularity, renamed in commit e4ec3318a17f ("sched/debug: Rename sysctl_sched_min_granularity to sysctl_sched_base_slice"). Under EEVDF it is the default base time slice / request size (r_i) used to compute the virtual deadline, as documented in update_deadline(). - Two comments still mention sched_slice(), which was removed when the fair class committed to EEVDF in commit 5e963f2bd465 ("sched/fair: Commit to EEVDF"). The dequeue-path comment should simply refer to the task's slice (se->slice); the forced-idle comment describes the slice accounting now performed by __entity_slice_used(), which is the function actually used right below it. No functional change. Signed-off-by: Zhan Xusheng --- kernel/sched/fair.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index d78467ec6ee1..599ff23f52d3 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -72,7 +72,10 @@ unsigned int sysctl_sched_tunable_scaling = SCHED_TUNABLESCALING_LOG; /* - * Minimal preemption granularity for CPU-bound tasks: + * Default base time slice (request size r_i) for SCHED_NORMAL/SCHED_BATCH: + * + * Under EEVDF this is the request size used to compute the virtual + * deadline; see update_deadline(). * * (default: 0.70 msec * (1 + ilog(ncpus)), units: nanoseconds) */ @@ -7974,7 +7977,7 @@ static int dequeue_entities(struct rq *rq, struct sched_entity *se, int flags) se = parent_entity(se); /* * Bias pick_next to pick a task from this cfs_rq, as - * p is sleeping when it is within its sched_slice. + * p is sleeping when it is within its slice. */ if (task_sleep && se) set_next_buddy(se); @@ -14571,7 +14574,7 @@ static inline void task_tick_core(struct rq *rq, struct task_struct *curr) * if the sibling is forced idle, then trigger schedule to * give forced idle task a chance. * - * sched_slice() considers only this active rq and it gets the + * __entity_slice_used() considers only this active rq and it gets the * whole slice. But during force idle, we have siblings acting * like a single runqueue and hence we need to consider runnable * tasks on this CPU and the forced idle CPU. Ideally, we should -- 2.43.0