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 60C5A3C5DDE for ; Mon, 8 Jun 2026 14:04:51 +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=1780927492; cv=none; b=qU9Er8d0u2tBP63u2vXHEcwaCVZefLktWyb/BpLGhY1GKSYac0Nx5MwAujvkj32NjarPhgwnXN74sm5fEB6swFIfs4ex6HBSUOZoRJZHE3GgBbsb4ixeQ40C/0mNyqRRqi0AeOkdp1/FUMFWoZzPWQ6mZbAMXuPbJuGM53NdydM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780927492; c=relaxed/simple; bh=UjxnU+eMnFdI8E5kdB9a/tNl9zGMt6HdsINWE8fOu5Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kTEwNtQcTywHqTU72hNailrDgyVVz5alhy1WPxnHWwlBcTJrnnAw7vVniJs8PSnsgPHwhApYCJwBlGBxbIFcvNHra1S+SBM5kahuj8DcqR4KEHAgP1VDfoO55PuXyJsAavH8jHRt4NYRbQ6pmuZu7PSt3imOPYRT8iAgADFGt/0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hgETCqAO; 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="hgETCqAO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4876C1F00893; Mon, 8 Jun 2026 14:04:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780927491; bh=Ye1mQXIXOcVzoRPUud6l40LUGGO/vAOZ6rvK6KBqUIo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=hgETCqAOpRdPaNkze3W9kC1ZbP2E/7peIZtCHVYwAFnCuqtIJoEJw4BZMKI5fnt00 xKPJOCUAO32ooiaAtLx+02TRKD9Qj0vi6aE7LNThIcuGS5tOTfe7YPNQE9hWqGSNMR PXVFzAxhI+YMhzSCVKGitjuiGfp5jlHBTdXri0IPwFsP/6sapr9zO+dGvqb2udzwCJ se/rS/t9pakK1k1d1BSBHzahomFAp91ChPIJJjuGW5Nw9M3SlYdrZ6T2oRRPP/rJiy 6h1SGlmKmRkyrKY9Y4+HRLSFI3qm55EGWyZR+M4+sIcX4EFmKEzsS2sKG4khM6pBZ1 OppyaFq7abJuw== Date: Mon, 8 Jun 2026 16:04:45 +0200 From: Frederic Weisbecker To: Marek Szyprowski Cc: Thomas Gleixner , LKML , Anna-Maria Behnsen Subject: Re: [PATCH 1/2] timers/migration: Fix hotplug migrator selection target on asymetric capacity machines Message-ID: References: <20260519220926.63437-1-frederic@kernel.org> <20260519220926.63437-2-frederic@kernel.org> <928989ef-8cca-4956-aeb6-3cfe5a74785c@samsung.com> 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: <928989ef-8cca-4956-aeb6-3cfe5a74785c@samsung.com> Le Mon, Jun 08, 2026 at 11:45:37AM +0200, Marek Szyprowski a écrit : > Dear All, > > On 20.05.2026 00:09, Frederic Weisbecker wrote: > > When a top-level migrator is deactivated, either at CPU down hotplug > > time or when a CPU is domain isolated, a new migrator is elected among > > the available CPUs and woken up to take over the migration duty. > > > > However that election must happen at the scope of a given hierarchy and > > not globally, which the introduction of per-capacity hierarchies failed > > to handle. > > > > As a result a given hierarchy may end up without migrator to handle > > global timers. > > > > Fix it with making sure that the new migrator belongs to the same > > hierarchy as the outgoing CPU. > > > > Fixes: 098cbaad8e57 ("timers/migration: Split per-capacity hierarchies") > > Signed-off-by: Frederic Weisbecker > > This patch landed recently in linux-next as commit e4a70f5fbd43 ("timers/migration: > Fix hotplug migrator selection target on asymetric capacity machines"). In my tests > I found that it breaks system suspend/resume on some legacy big.LITTLE ARM machines. > > > Reverting $subject, together with dependent commit d4f198c13611 ("timers/migration: > Deactivate per-capacity hierarchies under nohz_full") on top of linux-next fixes > this issue. Here is the log from the system suspend/resume failure introduced by > the $subject patch: > > > root@target:~# time rtcwake -s10 -mmem > rtcwake: wakeup from "mem" using /dev/rtc0 at Mon Jun  8 11:17:23 2026 > PM: suspend entry (deep) > Filesystems sync: 0.000 seconds > Freezing user space processes > Freezing user space processes completed (elapsed 0.002 seconds) > OOM killer disabled. > Freezing remaining freezable tasks > Freezing remaining freezable tasks completed (elapsed 0.042 seconds) > printk: Suspending console(s) (use no_console_suspend to debug) > ... > Disabling non-boot CPUs ... > ------------[ cut here ]------------ > WARNING: kernel/time/timer_migration.c:1505 at > tmigr_clear_cpu_available+0x3b8/0x3c8, CPU#5: cpuhp/5/40 Thanks but which tree is this? The only warning I see there is on line 1521 1532 (tip:timers/core). It's probably line 1521 somehow. Is it possible that arch_scale_cpu_capacity() returns a different result between CPU boot up and CPU down? Thanks. -- Frederic Weisbecker SUSE Labs