From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CA36C8634C for ; Tue, 16 Jun 2026 13:33:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781616832; cv=none; b=iR6oGiQzVYr5k5vp9ky7o7W3a6xuIdzrcki8vRcABsxrROyyf+0jM4ZjnbuH4CY6OmiZc+4ppAMFo4fYgPAdTQlK7m03PdKHpyt5SkiQAw9wJPcSubaUGDTFGrDEsIygip9YHbvcF9pBYomDePEAghh+up4AMurHdOlk62ki4T0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781616832; c=relaxed/simple; bh=MLSZdnvTKRXrN4gsrVsAepNGtdszx+A9KHuVoDC/daU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=JAQYKWqTF4btHQPxQbWraiCxLvfgO0XeveYW7LApzCMhFp0dHH6v87SrMEp3L4rKY3VeMQMBgFMXOg5G4W2WECBdmDjU5Pq2MkZOlDB19eWU/RiCnAeQolDap9sZgRquyOE1YSKStrMkSHkXn6ozedjiaC1Qd0DM8QzJRXYYmgI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=ALuCpwnb; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="ALuCpwnb" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E09C835BD; Tue, 16 Jun 2026 06:33:44 -0700 (PDT) Received: from [10.1.27.69] (e127648.arm.com [10.1.27.69]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CB4103F763; Tue, 16 Jun 2026 06:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1781616829; bh=MLSZdnvTKRXrN4gsrVsAepNGtdszx+A9KHuVoDC/daU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ALuCpwnbIkNe39Bxh3OS6qDCb3AnohGXitZlngEHPHfEGJQbB+ANi4TZotO/IxVlh wIVuMozfirpn0do1xGzUoYKsTex2eOdlak/eZ4zPDzd83ds/0/eSgLneWaGZjbGvia bcpwb7pIpfym3167s62s5r9MXUED/mhDd1Aox4ak= Message-ID: <957bd8eb-c5ea-45d4-8540-796fe1a44016@arm.com> Date: Tue, 16 Jun 2026 14:33:47 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] timers/migration: Temporarily disable per capacity hierarchies To: Frederic Weisbecker Cc: Thomas Gleixner , LKML , Sehee Jeong , Anna-Maria Behnsen References: <20260609123356.28449-1-frederic@kernel.org> Content-Language: en-US From: Christian Loehle In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 6/16/26 14:32, Frederic Weisbecker wrote: > 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. > Sounds reasonable to me, happy to give that a spin!