From nobody Tue Sep 29 04:13:33 2026 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (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 29CAA381EA1 for ; Wed, 12 Aug 2026 15:10:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786547415; cv=none; b=HM64UzeRmkTNKiynX/hMxERAT5BDwGjRD1hBMcIe+ZDsMNlbG5OyItA9QfjStXeipy8J8+8O0JljPFf4NlGyriSt0UWxKwh6AzR7C1LGDt3nv7aHBysHff4A/L5P9qT30tlgwk8blI4xuHzYAhkGAimKnfzOQb+bPkFqzRpB6vw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786547415; c=relaxed/simple; bh=3XhJAfWuwUaxwLLwcy8rly6iHdRZ8ElwvNN+V2VhdJg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=QiiVRvgGkUvr0dAuUF4uYctPe+g7v3G3nZsvuKk3JWdqPNljSVh1c7oOaTv5Uh/3Qk3vpKXy7MfQYBfju45NnqNyC9ySI310afk8GsXmjO170ARJkJjlk0fAdwuSequjlHwh/TNzfDV5oiVTGaOx2o31DwaYphhNNG++SuOnuOY= 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=XWTt4BfC; arc=none smtp.client-ip=209.85.221.53 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="XWTt4BfC" Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-47f5d5dbf80so39755f8f.2 for ; Wed, 12 Aug 2026 08:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786547412; x=1787152212; 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=Lgrb2OBOShSDNEjRQ09Rk2AX2IzxDNl3Eupq/vB7XPY=; b=XWTt4BfCO/jL5RJpXa6E9lhE79+GwL5I5p0Odz1I6El3Q24ffC4GugOVloiQ6aQvZQ xBv77zwlgBvN0jRCua7AsdggdLXEscZbNBV0Jw2KaRcvCv7glkXwYj1L+zv5oDYJ0CAf cWjGcJyI+LcnYnIMCQRi6EFfMKg55F38DvuM71f/d5jW8PKlIGHDebFHfNBakCyb1UDA 7j1RruYDyqegk8noduaFMlXBbY7w3tQf18J8kM3VySaRVafB6hR8g8rA8ETMhuELXha8 tpvPmQY6as+L1kDIq9d9JKgHhuksnDGoFBnTAH8Gd3OspDHrBtEdqi6siy9Njv/KWALc 3+Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786547412; x=1787152212; 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=Lgrb2OBOShSDNEjRQ09Rk2AX2IzxDNl3Eupq/vB7XPY=; b=TdQr7kqpi7nEkJf/R82maOJ4ccnHzWqpUIjaezFDUqDKzRhv9IH7DP+cc0CBKxFMBZ Y/CrluBh/F8WCswFBgny3luXFa2htxYmpqkvbN/LMH6uIXlXeFu/EjFPN3zVYBcTl/sq A/nuU7fM+/GHfWggP/2FQjGiavP753DuBavDVFk30bao3W3/1nHTZacOcu5D51OJrF4I f9jcLz/VbKZHQA+wx0dKV6C5Jb+QwoMNY3anlooauvopqPqhljL5fPKvui8EFJ12ExBv zCpu21lSbxzq7OBuYop2Dt6E4cnPwXqUlHnUrCDfpY3MaDrwZe5+xv1mz4LQsfFyhja3 GCEg== X-Forwarded-Encrypted: i=1; AHgh+RrqqchvD7lBDgc9CjQ3KW4ii+PI/0U+rcDhuFsBhZQSiz5AELu2Nu2Ig8SFO3YREHewVqSo5wPFQgSqvCo=@vger.kernel.org X-Gm-Message-State: AOJu0YxU60Rw1HrTleNEC5lTrHy80KXZxDrw2EQ+N2u3x/lqslAQ2Ywd 2a8sAhm6IUOufezd49Yaic8aRN/dyHYdWeVHmAWRiiD2PQFNflEzebkS X-Gm-Gg: AR+sD12hththM5CItmqYCPfnU6tQzLcLyTbZ6xVVAydpT+J6qbQXMAxvePOVnncUTgh zsqKfyhCQ+pVaQPmpInZI9mC9pFlk+H9lZT/xt2n6+JaYPcZ2Eyl/dJQrN3GwipCyUNwYR2fXsL q/VefReq6IlUMj6ZN2fv6Y9KqBrfa0fna/ybzpismKzAN5pIESkBLzJffEF6zJAyrmiiiT8bgRk /FLQj3MLXNoFQZirwRepjhUp+HLhYTWg0uAHKu8K6rxS9P5XaHzC8gQ9rCxye4Z9UrS/FkIZUsN YlqJuHpzsCMQXWaWjuAz3WVQacRQJZcbxLhLGsO4WF2iwdF7Uf6+1YS8CNGIWs9WIZ6baVoM99A KcanmjtlsnbxxOsYk1Cqm/FZTzPGaXIdmgVi9HAmdK2fQLDifOj6FOt8xubAdrOZOdujiDtU2wp 9xrj7rWTnsJwSMyPTKsOye/k62GdSazAdNlAfoBIWah7D2+PEMzgBDrGbsuI4QamXJdj8DuHgpr Kfe7ZzmySbapmXZ0K4jaQ== X-Received: by 2002:a05:6000:2603:b0:47f:91f0:9ab with SMTP id ffacd0b85a97d-4815277a28amr3909622f8f.0.1786547411949; Wed, 12 Aug 2026 08:10:11 -0700 (PDT) Received: from lima-kdev.local ([85.99.183.171]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48150c06ab7sm7574575f8f.10.2026.08.12.08.10.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Aug 2026 08:10:11 -0700 (PDT) From: Kayra Cizmeci To: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , linux-kernel@vger.kernel.org (open list:SCHEDULER) Cc: Kayra Cizmeci , linux-kernel@vger.kernel.org Subject: [PATCH] sched/fair: Avoid calculating curr's key twice in pick_eevdf() Date: Wed, 12 Aug 2026 18:09:58 +0300 Message-ID: <20260812150958.141846-1-kayracizmeci@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Currently, pick_eevdf() calls entity_eligible() with cfs_rq and curr that calls vruntime_eligible() and gives the curr->vruntime as the parameter to vruntime_eligible(). pick_eevdf() checks if curr exists and is on rq before calling entity_eligible(). That means when entity_eligible() is called, the first 2 checks are not needed since we already check them in pick_eevdf(). And the key value is calculated by the given vruntime (That is, in this call path is curr's vruntime) minus zero vruntime. But above, we do the same calculation with entity_key(), that does the same calculation with the given entity's vruntime. But the given entity is curr. And our parameter vruntime is curr's too. We do the same calculation twice. Add curr_eligible that skips the curr exists and on rq checks and calculates the key once. No functional change intended. Signed-off-by: Kayra Cizmeci --- I boot tested the changes on x86_64 and checked if the behavior would be the same with checking the results with WARN_ON_ONCE. I also ran some tests with perf stat, but the results we're noisy, so I thought that making assumptions with them would be wrong. kernel/sched/fair.c | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index d78467ec6ee1..2ec3040bc479 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -936,6 +936,33 @@ static int vruntime_eligible(struct cfs_rq *cfs_rq, u6= 4 vruntime) #endif } =20 +static int curr_eligible(struct cfs_rq *cfs_rq) +{ + struct sched_entity *curr =3D cfs_rq->curr; + s64 key, avg =3D cfs_rq->sum_w_vruntime; + long load =3D cfs_rq->sum_weight; + unsigned long weight =3D avg_vruntime_weight(cfs_rq, curr->load.weight); + + key =3D entity_key(cfs_rq, curr); + avg +=3D key * weight; + load +=3D weight; + +#ifdef CONFIG_64BIT +#ifdef CONFIG_ARCH_SUPPORTS_INT128 + return avg >=3D (__int128)key * load; +#else + s64 rhs; + + if (check_mul_overflow(key, load, &rhs)) + return key <=3D 0; + + return avg >=3D rhs; +#endif +#else + return avg >=3D key * load; +#endif +} + int entity_eligible(struct cfs_rq *cfs_rq, struct sched_entity *se) { return vruntime_eligible(cfs_rq, se->vruntime); @@ -1157,7 +1184,7 @@ static struct sched_entity *pick_eevdf(struct cfs_rq = *cfs_rq, bool protect) return cfs_rq->next; } =20 - if (curr && (!curr->on_rq || !entity_eligible(cfs_rq, curr))) + if (curr && (!curr->on_rq || !curr_eligible(cfs_rq))) curr =3D NULL; =20 if (curr && protect && protect_slice(curr)) --=20 2.53.0