From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (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 C4B923254A5 for ; Sun, 17 May 2026 16:09:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779034169; cv=none; b=QJTWHeBUOxQkBE6ERQ2nl4pLAzK4Vd4r3WqrpATkhtJkLQKeEdIq7c5bgwBrVBb+8Pw6V/1i8AOwso5pXsmChR70tFfDZNq8nQa+kUY70s/ghgnz71EhHfxLRCXyyB5Df6oUZ0NXdEhcSiJvHF/EAqfig3yP/lDbTFSCCGj98Nc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779034169; c=relaxed/simple; bh=V6txJHIlMMdeTbYw1xAUAO8pf7rL4zdkchtecoknKGU=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=l1xFLuysipDVgC3dwmUHkCw4bd8VWb1VRyWYbudQ6abB/T0iioSX5FNhCpHHjUmzAvZ76OMaus+w27VrNyONBthyKMD3DJ8/hSFwvmEKCOPpyYcbEBfSAxx97xMtrUR6tRC6bca0ME4UoxvK9lOdYr10Xn4nfYnOSAnw6nF01kY= 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=sipr19Wu; arc=none smtp.client-ip=209.85.221.52 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="sipr19Wu" Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-449de065cb3so1333545f8f.2 for ; Sun, 17 May 2026 09:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779034166; x=1779638966; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=sTRl50NYboJlKVM29C8080a4lyWgcwXvU1Nmiz0fxno=; b=sipr19WuIIYbjTpZlHNT+21RybJJ/GXWd3DhdogqLUh4K6GMhQ3v74Mj5hsWhYtyNj OPh7q0Mi3EDIlqo97lMmhNeL6h5TiAJ9laLRufgqMU19zlthvVlhQB2TTTXlYmtc5qN8 Qday0FP8YFjGmqbFkWkyds3NTlBoyeUmIKuXHOdTH6OR+OPxSgVsN/Khy/nFWkZtoysq SOx0jWwAhPXZxYmdzDz+kHskJAZBnO+2qCrNbEYj6jsNWUpUOj+vOuSQnlG5m5neeriU 2xmFENiO7ZrP2FmTk4KVjQKYRRqd96R/49iIsWjaBK+ylR9pJLNm9FzzDSOxfivGFJZQ UDkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779034166; x=1779638966; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=sTRl50NYboJlKVM29C8080a4lyWgcwXvU1Nmiz0fxno=; b=Wa12HqF72Sqln1oJi/mckW1WbEH0fELOkExtL9PDTSQlwSRGHwvQ/unaDFOkjOix4v UutIDhO5Wo4Tv25QmziNthdhTsoplsjpPd8oKIvsxqXMPnH6isqNje3hOBGlrNpoFTz9 4zzLXXmZ4t4AH5g9VDJ9ZtHLLfMvd+hUuBxQ4UASXE7UmtKMFdxUSMjC3YVLQ98t8yX4 wkMcZZqjiXdt6qKuJzd7YC7UpcsZpOoyw1fE6L7LLXtzHtZSfblCLptZVGd/8goZYVQt cgSujOUchs9eQ1SxHuzUvCxx38u1LCk8aK5yKeumQ5reyL9T7ForVk2gRIFde5+ttLVc 7FKw== X-Forwarded-Encrypted: i=1; AFNElJ9m2Wx32knic1YRNVGDpYReOlHUJOOQsQAmU7od4TTsOEmpxGQF09nemjd9OmCyn1pWwOwxrDF4Jwk3bhs=@vger.kernel.org X-Gm-Message-State: AOJu0YyyiQbgC7Z38gDiG+RAfdDToPZReeSwGvonXzvjg3e/Yq4PmJZi 09blQFQUrTT2vWBcFf6A6JWe/lE6HXw3tpyuOdm6symIFbrZVnNhM0+iaeRIIXvZ X-Gm-Gg: Acq92OHKPeTUC0QsQiIUWhTPumixiehmg72cj4x+KD6NIm7k3+68T2fMDdggglhMS95 q7HHromtJjwV7gSJZsJ8l18fJK3limkD0Tt4+1x3nUh/w9Tvjdq9sWZkf64JES9OM+JrjWMyoEk 6VT2bTgvZ5VHwoTBMeKhMzH+p1c3E2z6vOzR3W6JR37Q+hmLj5Hqb6i52Msdu0blpNbOhD9bLK4 /L1pEup2cd+kFjRaKql2o9yHhOMY/hXBCguHqrjC6iY8L0THYgeCXDlnaRLpn/NKRrmH2/fFfdj 2w24FWPhwj3ZNHzTZvxwf/qk+dqkBVFpS5RnsNts4/mMwcfJmw8f12WvcL3tjXkLZ8NSg8Gn16T ZHMyUmtsQPRICoGOlpM++gUW4zEjfm78C9NdfY5fb1flfoHaJlG7QwGgn4lXN9Ur2W2tBvyi8Yg R8SJxgr5V+tPHRSg9K52FqQ3hdU7YroxZZnGIUMu3q6q5M6hwmLOvW1bLVHcK5pjs44nST7mP0X SA= X-Received: by 2002:a05:6000:40cc:b0:45a:c0e1:37b with SMTP id ffacd0b85a97d-45e5c5ccf6fmr17330277f8f.32.1779034165815; Sun, 17 May 2026 09:09:25 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45d9ec3acf7sm30329533f8f.12.2026.05.17.09.09.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 17 May 2026 09:09:25 -0700 (PDT) Date: Sun, 17 May 2026 17:09:22 +0100 From: David Laight To: Qais Yousef Cc: Ingo Molnar , Peter Zijlstra , Vincent Guittot , Juri Lelli , Steven Rostedt , John Stultz , Thomas Gleixner , Frederic Weisbecker , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/3] sched/tick: Decouple sched_tick() from HZ Message-ID: <20260517170922.0bd83513@pumpkin> In-Reply-To: <20260517154401.5b5qk3ixujsbkqhx@airbuntu> References: <20260517040740.444729-1-qyousef@layalina.io> <20260517151041.10a9a355@pumpkin> <20260517154401.5b5qk3ixujsbkqhx@airbuntu> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 17 May 2026 16:44:01 +0100 Qais Yousef wrote: > On 05/17/26 15:10, David Laight wrote: > > On Sun, 17 May 2026 05:07:37 +0100 > > Qais Yousef wrote: > > > > > Previous attempt to make HZ 1000 the default [1] to help with scheduler > > > responsiveness didn't get merged. But maybe for the best, as I think this idea > > > of decoupling sched_tick() from HZ makes more sense. We shouldn't need to make > > > a choice between how often timers should trigger vs how often should the > > > scheduler update its stats/take decisions. > > > > Have you also looked a decoupling HZ/jiffies from the timer interrupt rate? > > It ought to be reasonable set HZ to 1000 and to do 'jiffies += 4' when the > > timer interrupts 250 times a second. > > I'd expect most code to handle that fine. > > John actually had a stab at that [1]. I'd forgotten about that - even though I commented :-) > I am not sure we can fully say we don't care about what TICK_NSEC means. And > all the open coding with HZ. > > I don't see value in the overall potential treewide conversion and the > potential compile time math becoming 'runtime overhead' complaint someone might > throw out. If HZ is fixed at 1000 then there is no extra maths. > I did have a stab at making HZ a variable and update TICK_NSEC to depend on it. I do remember that, and thinking it would add a lot of extra maths. ... > > I know one architecture (forgotten which) traditionally used a 1024Hz clock, > > and some very old ones 60Hz; but I don't think Linux supports either. > > Personally I think HZ=1000 is the only sensible option. But I am not going to > fight this battle :) I go for only allowing values that divide evenly into 1000. That really only gives you interrupt rates of 1000Hz, 500Hz, 250Hz, 200Hz and 100Hz (and maybe 50Hz). -- David > > [1] https://lore.kernel.org/lkml/20250128063301.3879317-1-jstultz@google.com/