From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (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 8CB665789D for ; Tue, 28 Jan 2025 06:33:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738045996; cv=none; b=iCNH39fmpXsQXpT0GMnptPWajGdXskeTU/hcNbtVjObrZOMtlSeVTmHyvtIfEEQHNd7lNFfNxscRTWxhO4vbMmDKHPeXZDNKN7E9SNARsdKICApYG8Xi2zMbeoSDwJHJFvdL4WdZqHnVfgDo6SfApOksQVXRJ2ZtXjCLQHmt86A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738045996; c=relaxed/simple; bh=n5ic0ZAC90MVrXe5x6ygqNQUg3S5jD7b5roQYwdVRsw=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=sJTBi5HgpoUjY0Z83+NNSE3Xa0b1UlLAEG9AzGfI25Kd3I0C0HRPMdtGuWWNZqZJ5SFFz/TDbCsp1ZhoHL4rakVeqyGu+OUuMIoMIimrD9q+EGZvS8nQ5XrnyQVcxHHIfGm5D9TMs3xLAFgeWkvoQQYw0dqmmiRU9TITWTtrf1o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jstultz.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=z3eECAk1; arc=none smtp.client-ip=209.85.216.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jstultz.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="z3eECAk1" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2efa0eb9dacso10634723a91.1 for ; Mon, 27 Jan 2025 22:33:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1738045994; x=1738650794; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:from:to:cc:subject:date:message-id:reply-to; bh=LWDMJkNZ6UaOr9SXmW9T5rZP3zKpRoEhjg/uyMQIe4U=; b=z3eECAk1GrfS3Kb9hTaxGZQdjAhqdFiQCuwBx0n8KqKb1wYT0Pn5HmBebPHPWCrMIP ViJKmXF32Rm9sn8hSPxS0opDi5qJLVEanMUa/IHBMjJqVFPdGBifFG5BzxE4H6m+POM/ ZZhq6Q6AE9UMpZX48lzVRMNqUNaoUe6ESXnQWG11HkBlN+Nwn93mOrSzrfpJ96WRDOXo Ved8RnfOV7D0yv0WEx86+FaZ2AaQsnIbeZfAdMbiQxibRImguFjgR+Wk01vVI5Sdy8o7 F2SCvCpp8897O8srTH8MkDxO5/rp/2QCWlJFeiI1cTHv3igbQ+zyxDkjgvdxSRvtOefH m/MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738045994; x=1738650794; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LWDMJkNZ6UaOr9SXmW9T5rZP3zKpRoEhjg/uyMQIe4U=; b=PiHIFf79iDVwywUjAeYx95gV+dbUB0BdFnrQsxEorxiVCrjVTrsBgF8aZjjbJT/YDL C5LQtJL7qZ3X/BrXkVTE3+c//nQBui6BG+WS74Kg8beKqBpe2WeOQYZjNic1KHS53mY/ TSp2atdsRSTgYxY0d6RWgbjnx3bAl/rTXr0rG9vwd+YrlC9ErH206W6JJCHoJk0lEuh/ j6Nbn7JY6mFu7o0b5JBtq+GEhFawHKWUUoe6mbykHpp/juoScX9H85g/GB8DdnLYqDxo ocBP61NDJ+kCmMcRNjuZQLmyy3Do07TTyaKxlvDkYyCehqvyY7oYxpUYwFsstRi2IG5g o+9g== X-Gm-Message-State: AOJu0Ywr3WPBj/xhcKyveki51j9Hi4G8HtH2eJOQjnkE57DdeICJnffs cY3H08Vz965fn1PcetJ5ztReToysjQjOepDv5P4RwR8M7gDbOF9cVcmAoITSpifRL5ZJa9k8h05 grj8tRzcHnT9ZWx/wtqjS23ey8Jm1bhHI5BuX3Q04SZhNVGPpUkDnjuWXzoHZ/xLZ0lzeDyxS3v UDNzbkXZqfIYuKq6ZqeNDdubSm3ZVJPAV24a7SXJ6QsjNQ X-Google-Smtp-Source: AGHT+IHNpeNxP0yooICPyyLizGUbRDCwf8EpV0XELjf9T9uACM9yyy6v9vgb56KFGU/LXNt9GvZ+JMpl+BtG X-Received: from pfwy36.prod.google.com ([2002:a05:6a00:1ca4:b0:72a:9fce:4f44]) (user=jstultz job=prod-delivery.src-stubby-dispatcher) by 2002:aa7:8f89:0:b0:72f:5950:13ad with SMTP id d2e1a72fcca58-72f59501d17mr32624787b3a.20.1738045993658; Mon, 27 Jan 2025 22:33:13 -0800 (PST) Date: Mon, 27 Jan 2025 22:32:52 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.48.1.262.g85cc9f2d1e-goog Message-ID: <20250128063301.3879317-1-jstultz@google.com> Subject: [RFC][PATCH 0/3] DynamicHZ: Configuring the timer tick rate at boot time From: John Stultz To: LKML Cc: John Stultz , Anna-Maria Behnsen , Frederic Weisbecker , Ingo Molnar , Thomas Gleixner , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Stephen Boyd , Yury Norov , Bitao Hu , Andrew Morton , kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The HZ value has long been a compile time constant. This is really useful as there is a lot of hotpath code that uses HZ when setting timers (needing to convert nanoseconds to ticks), thus the division is much faster with a compile time constant divisor. However, having to select the system HZ value at build time is somewhat limiting. Distros have to make choices for their users as to what the best HZ value would be balancing latency and power usage. With Android, this is a major issue, as we have one GKI binary that runs across a wide array of devices from top of the line flagship phones to watches. Balancing the choice for HZ is difficult, we currently have HZ=3D250, but some devices would love to have HZ=3D1000, while other devices aren=E2=80=99t willing to pay the power cost of 4x the timer slots, resulting in shorter idle times. (As an aside, some suggested RCU_LAZY would avoid the cost of bumping to HZ=3D1000, and it does indeed help a good bit, but we still see higher power usage compared with HZ=3D250) So I=E2=80=99ve been thinking and talking about an idea for awhile to try to address this: DynamicHZ. The idea is we just set HZ=3D1000, with 1ms granular timers. However, using a boot time argument, we can optionally program the clockevent that generates the timer tick to fire at a lower frequency. Effectively this is just like the lost ticks handling done for SMIs. The jiffies accounting is handled by the time the clocksource sees pass, so time progresses properly, and timers for all the ticks we skip will fire when the next timer interrupt occurs. So with dyn_hz=3D250, the interrupt fires every fourth tick and with dyn_hz=3D100, every 10th. So far, this approach has seemed to work ok. One area that needed adjustments was the cputime accounting, as it assumes we only account one tick per interrupt, so I=E2=80=99ve reworked some of that logic to pipe through the actual tick count. Once that was addressed, in testing with HZ=3D1000, dyn_hz=3D250, all of the time/timer tests I've tried seem to be working properly. I don=E2=80=99t see any performance regressions on tests like Geekbench(compared to HZ=3D250), nor have I observed any power regressions. Though as the tick and scheduler code are intertwined and neither subsystem is particularly simple, I expect I may still be missing or forgetting things. So I wanted to send this out for review and feedback. I=E2=80=99d love to hear your thoughts or concerns! Also, I've not yet gotten this to work for the fixed periodic-tick paths (you need a oneshot capable clockevent). Mostly because in that case we always just increment by a single tick. While for dyn_hz=3D250 or dyn_hz=3D1000 calculating the periodic tick count is pretty simple (4 ticks, 10 ticks). But for dyn_hz=3D300, or other possible values, it doesn=E2=80=99t evenly divide, so we would have to do a 3,3,4,3,3,4 style interval to stay on time and I=E2=80=99ve not yet thought through how to do remainder handling efficiently yet. thanks -john Cc: Anna-Maria Behnsen Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Juri Lelli Cc: Vincent Guittot Cc: Dietmar Eggemann Cc: Steven Rostedt Cc: Ben Segall Cc: Mel Gorman Cc: Valentin Schneider Cc: Stephen Boyd Cc: Yury Norov Cc: Bitao Hu Cc: Andrew Morton Cc: kernel-team@android.com John Stultz (3): time/tick: Pipe tick count down through cputime accounting time/tick: Introduce a dyn_hz boot option Kconfig: Add CONFIG_DYN_HZ_DEFAULT to specify the default dynhz=3D boot option value include/linux/kernel_stat.h | 4 ++-- include/linux/tick.h | 11 +++++++++-- kernel/Kconfig.hz | 19 +++++++++++++++++++ kernel/sched/cputime.c | 6 +++--- kernel/time/tick-common.c | 32 +++++++++++++++++++++++++++++++- kernel/time/tick-legacy.c | 2 +- kernel/time/tick-sched.c | 33 ++++++++++++++++++--------------- kernel/time/timekeeping.h | 2 +- kernel/time/timer.c | 4 ++-- 9 files changed, 86 insertions(+), 27 deletions(-) --=20 2.48.1.262.g85cc9f2d1e-goog