From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 08C772BE026 for ; Tue, 16 Jun 2026 13:32:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781616772; cv=none; b=ZqdbvLar5HCpHCA5UZIBpywW1k+aLQu08Bx/ZHq1mEd9iSIylJZJlfnm+ec9ERV8hdVgr7ofCK2z3hZ4lreTjwmExUDK0XuZpBaWwSFqUzkTBG/35RSc3qN2MiWFDfP+me9vGb43wTi4dkB56r+3MDgSNwKVJdzbUCyN8CuLA+Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781616772; c=relaxed/simple; bh=UYn1fCxUe0HvF0Oenf1r0da9aiFDY867psUGlFVDMsI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GkjmCYUiTkOxXZd+sjrP/64Se6wFNQubUExMqHioeaWRH1p0fKQ9+buQAynCQ/z+DOV15KUdIazWWsbSKHso0UnED3Jdh8ZWDXsMJmiiAQxUhtum4QdB9aVA5z/t1dhnXeGYUGeIkDcNMnUF+vCzfSYrlYm3IYGnWbDOGHSWxNw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SAUA3XCy; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SAUA3XCy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 09E3C1F000E9; Tue, 16 Jun 2026 13:32:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781616770; bh=8BVHtOH1fUC8d0M/y4IErbqC01XQziPEpW7rOD21URM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=SAUA3XCyYSC7IDhfpIRtO4RMHtF4lGfPZ9wdvQxAljwyWIa7Zmnfboir7xIO3gdtF 3mPjTZBfphxyB+YI/XJ/sMikGIFzT7FbxVrggg6hQjo0rZVpQTCwb/p39udFsE+1st 3DIv/jViG77+DgHYqcfWoaufnDlw7kNUoW/T2cBta7n5fEct/GFO6jCDyE4M31cupR 5R2isP8mpIaGuVvpROnJF94zOVVdhAzM/ah5HxmwYr+VayFstpUqKirSV2BWm8WUXE 0RnOHM9AkEHyKVpOzUlXtVL173SCeIDf6eW0ni7f5bvE/lgfKLhQ7nY4fBSIROj0J4 35AYbYuU7NxZg== Date: Tue, 16 Jun 2026 15:32:47 +0200 From: Frederic Weisbecker To: Christian Loehle Cc: Thomas Gleixner , LKML , Sehee Jeong , Anna-Maria Behnsen Subject: Re: [PATCH] timers/migration: Temporarily disable per capacity hierarchies Message-ID: References: <20260609123356.28449-1-frederic@kernel.org> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Le Tue, Jun 09, 2026 at 04:34:17PM +0100, Christian Loehle a écrit : > On 6/9/26 13:33, Frederic Weisbecker wrote: > > Some workloads with different CPU capacities consume more power with > > timer migration than before. The recently introduced per capacity > > hierarchies were supposed to alleviate this problem. However it appears > > to also regress other types of workloads, especially when plenty of > > capacities live together in the same machine. > > > > Disable the feature until a reasonable solution is found. > > > > Fixes: 098cbaad8e57 ("timers/migration: Split per-capacity hierarchies") > > Reported-by: Christian Loehle > > Signed-off-by: Frederic Weisbecker > > --- > > kernel/time/timer_migration.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/time/timer_migration.c b/kernel/time/timer_migration.c > > index 548d84955f4c..e9d96d96e251 100644 > > --- a/kernel/time/timer_migration.c > > +++ b/kernel/time/timer_migration.c > > @@ -1473,7 +1473,7 @@ static unsigned int tmigr_get_capacity(int cpu) > > * timekeeper must then belong to the same hierarchy as all the nohz_full > > * CPUs. Simply turn off capacity awareness when nohz_full is running. > > */ > > - if (tick_nohz_full_enabled()) > > + if (tick_nohz_full_enabled() || !IS_ENABLED(CONFIG_BROKEN)) > > return SCHED_CAPACITY_SCALE; > > else > > return arch_scale_cpu_capacity(cpu); > > FWIW > Reviewed-by: Christian Loehle > Thanks for looking into this after the late response! > > I have something based on avg_idle which doesn't look unreasonable on first glance, > I'll do some more testing and hopefully post it with some number soon! Here is another thing we can try. We can build the hierarchy just like we do with NUMA but instead of NUMA nodes, use the capacity (initial idea of Thomas). But connect them through a common root. This is roughly equivalent to per capacity hierarchies, but all those hierarchies are connected eventually to the root. And then upon CPU wakup, actively "steal" the migrator duty from higher capacity CPU. This way lower capacity CPUs have more chances to process global timers and they also have more chances to stay active due to that added work and also ground work tasks woken up by those timers (hopefully locally). I can try something like that, I'll just need to use atomic64_t for struct tmigr_group::migr_state to store the capacity of the migrator. Thanks. -- Frederic Weisbecker SUSE Labs