From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (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 13F733AB5C7 for ; Tue, 18 Aug 2026 15:19:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787066344; cv=none; b=jvFE/4Kr2AQNyatry4GoCL2TWnJU2meWQB2o2HJbKBkh7lWIP4zHel4SG40uwY/EgGpYoDsoJ2UAeNVAyH79GtGulp3CN/oH/mXJG0sYhUsIv4l/Xz2Qb6wJ5apKz1o4VDnY7wjQzEw8LiqsiTJLr3aqqZhT5mXg+YfiF2FGPTc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787066344; c=relaxed/simple; bh=3DsqXCcKyDPOSZHjDo1gSRB6hsjVUM5GokmQeSsqX5g=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=WOXkw4tC9zoaqK1aF+B1HEVdLXf1SZt8B+PQqXgpLX3TvQW371WEeZ0Pd/eQib0/nMMOuTdyBruX8rszzhV7+GffAZzdy791VOFYqGRIJFlgXBzAaImf3sUCUkS2PeY2ZybdkbSt0FUt4A0q389G1nhHxpZ8J3Gt0PypInnUD+c= 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=kX7XTcpc; arc=none smtp.client-ip=209.85.214.176 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="kX7XTcpc" Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2d5655cc850so35372685ad.3 for ; Tue, 18 Aug 2026 08:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787066342; x=1787671142; 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=PSN5DDKXN8jqOXU3Nl5daslqyqkgz6vCEcOwT5gsis0=; b=kX7XTcpcWFwQU5B3v7mj6Rb7Wc63JlCJTe8H/+/yH9yU7a8cDnpUNZVqMRGBTPlnKf OZrpx1dYaCWhPYZE24L7vJ104nL0RoBvKaDsl8td6rmwKf0uCKEWd4iEUJbxblPOzL+a L8axBZAL7xp4N6Mn9MiARVIUx+5HBATGtxNZYiN9Adq9qQzVp7fsF99m5mrvU9eUqgAG 6HMS8jwDUKKg+sw11EZgWDSXgwtrPrCZR/Qegm7a5Kan7Lh+mcmhtQUYtDV5BunQ1VmD wctcjg+pQ6qPMZf9TcLPZjQ4Q6uEvcyNAHgcdeYoJ5q7a9drhQYunvc5Ggavg6mKL7Ga RavA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787066342; x=1787671142; 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=PSN5DDKXN8jqOXU3Nl5daslqyqkgz6vCEcOwT5gsis0=; b=rPbzrOM4QC+N6gYL+zdfo/R5XRaylFYCkU3lhQoljMcNH8UwjRZ23Oll3VOX89O8CO 6yiUJ1VL0JfN/GcYcxb3q5OprbJvg5T0xzpie162F193GNqdp0f1CtVKeRgKzX/yBeid JtDITfZiyDsrYIVNd/jb39KEPSftFcksSlGRMD+1BHbxmGWGGPRUL7WP5a8wbZg8vvUj wj5sjksI0UWoeBySmi3WdObKxkCwGCK+VhV6bW0fQ/pQUEYXYhtY0FWbPPDnO0IVad1M kTCIUW69tStatq1Ccia3x5StyFlL54IQIGnSaLkFWMnvSvh5Pl1USxj5y1/Cw+zIFWn6 6TtA== X-Forwarded-Encrypted: i=1; AHgh+RoUEjw6/sDeU8G5lV5810OeEKwL4kYWAQSXk3wgL4F/PY+r6rGCJFUmjX4Sdyb1LgLXoq5Oi8VrYhWIgMI=@vger.kernel.org X-Gm-Message-State: AOJu0YzbMwMNEvtEuQ3ZLiBB9J2QFBZB75wcvdEa22FnsZpEypJqdScL l8GCEkcsv5tof4YgUkNn89O1ldxrQMaTWNP57aPdZuM1h8ZTf3Jj0wJM X-Gm-Gg: AR+sD11H0IgiXHj7WRMr9r1dhGgTLUIUAkE/3GbaudfohAiwBy6HyXsyYw4AI3AmRVb 5WkURcxxmum6tSIi2CCqWX6/6okYcPawWD469cJjuoAWsSc5eRJSeSPDRD21YAhnPOiKpIsE6iz B5qF8WfEwrj6F0NbUYP+en4GoCEuGqraDAVhf9FejhEj+5Bs7qhdLMkd3fB2NYk/pERcmOl7+CT 73YKYA1g7WvVzN5B+HFjJSOR6l35menCDRNsR0WUROdk635xFObzu2rxu2wuVZVkeE0SPVu1LGR qh6o24Y4DDArEWQ6B5lj1Lpl0XIPiYsxByGYX8ZeukXQjOhWcwGZru4noSo4OAf7PvJstIHpY6E qo6+8u7Bt7+IkMxW7HHCZVIzYD/E2xUu7cZTrI3p+BNqAyKuIyOIXZH7ayDZFOQJs97FI8viaF4 +laLnVY87JTR0c3uPGaNttlUCYJPIlqiaJlYJjij5Kx+Pc+x2Z/Rd2DuADT7M6lwFDOiMBO6eNc g== X-Received: by 2002:a17:903:1a2c:b0:2cc:f5aa:9513 with SMTP id d9443c01a7336-2d5c4f53efcmr138829685ad.10.1787066341999; Tue, 18 Aug 2026 08:19:01 -0700 (PDT) Received: from localhost ([220.196.228.78]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d5c1e93ca0sm16203985ad.63.2026.08.18.08.19.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 08:19:01 -0700 (PDT) From: Liang Hao To: Ingo Molnar , Peter Zijlstra , Thomas Gleixner Cc: Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , linux-kernel@vger.kernel.org, Liang Hao Subject: [PATCH] sched/hrtick: Name the minimum slice and derive the rearm slack Date: Tue, 18 Aug 2026 23:18:54 +0800 Message-ID: <20260818151854.9193-1-haohlliang@gmail.com> X-Mailer: git-send-email 2.50.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit hrtick_start() floors delays at 10000ns to avoid programming slices too short to matter and to prevent timer DoS. hrtick_needs_rearm() separately ignores expiry adjustments below 5000ns as not worth the reprogram. Define the slack as half the floor so an expiry shift of one minimum slice still crosses the rearm threshold. Name both so the relationship reads off the constants. No functional change. Signed-off-by: Liang Hao --- The 10us floor and 5us slack were introduced years apart. This patch only names the existing values and encodes the slack as half the floor so a one-slice expiry shift still rearms. Was the 5us threshold chosen deliberately to be half of the 10us floor, or as a separate heuristic? Any background on that choice would be helpful. kernel/sched/core.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index b77152edafd9..c2149b7c7a9c 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -905,6 +905,9 @@ enum { HRTICK_SCHED_REARM_HRTIMER = BIT(3) }; +#define HRTICK_MIN_SLICE_NS (10 * NSEC_PER_USEC) +#define HRTICK_REARM_SLACK_NS (HRTICK_MIN_SLICE_NS / 2) + static void __used hrtick_clear(struct rq *rq) { if (hrtimer_active(&rq->hrtick_timer)) @@ -938,7 +941,7 @@ static inline bool hrtick_needs_rearm(struct hrtimer *timer, ktime_t expires) * whether the expiry time actually changes substantially. */ return !hrtimer_is_queued(timer) || - abs(expires - hrtimer_get_expires(timer)) > 5000; + abs(expires - hrtimer_get_expires(timer)) > HRTICK_REARM_SLACK_NS; } static void hrtick_cond_restart(struct rq *rq) @@ -973,10 +976,10 @@ void hrtick_start(struct rq *rq, u64 delay) s64 delta; /* - * Don't schedule slices shorter than 10000ns, that just - * doesn't make sense and can cause timer DoS. + * Don't schedule slices shorter than the minimum hrtick slice. + * That doesn't make sense and can cause timer DoS. */ - delta = max_t(s64, delay, 10000LL); + delta = max_t(s64, delay, HRTICK_MIN_SLICE_NS); /* * If this is in the middle of schedule() only note the delay -- 2.50.1 (Apple Git-155)