From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 035E310F2 for ; Sat, 22 Nov 2025 15:02:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763823741; cv=none; b=fvuoyZYDrHoawIrCtA0NfF8uYUOXqOO1KbaA+9uRm22euXfO40S6M+lr+ZGtbCFEppZqa9a+PeMoFiDrOkmUk4KWk/km524zNxtNkl1JYx5JHko3j6A/lD4+eHjxCDSwM2DeGe5btsDrQ6I106KjHH8GwPzj/8whIELp9N4yVf8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763823741; c=relaxed/simple; bh=ogXAi9FIbzqgtIo8R4BywKcH3tL9sKGawYVT8uNp4Ro=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=VkKKGZBhjamM2P5HCEsS+kRgZf0bnmDiTPsvnj+arc3pOvBh51L7nGdaiD/I5l+HrOGSShchziGh4BfIWOP2QNopG2v6SpG7hvSyrCqCwJ42rLlZB1N25Xv7vJdpclpFueURDewG8httA2LkPmZ9bWXP5CCSunxmunKr+6nWizE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=r60Tz7XN; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=TICwJsZk; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="r60Tz7XN"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="TICwJsZk" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1763823738; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UJZ2NZoka7UCzKuTeBAXXE6vhBEjADNjFdksBoB0Etk=; b=r60Tz7XNumW/yg4lR3PbDARnQKK9PRLH38mnQCyQvWesXLqADrYSxMv+o+xWJ4XwhzOM+j VVu6R8mY/+zU3Trjz0kZtmBvXE3lKWksMdTqbqNuYylgtGmk3O7BMC0cJSl/YRPTXdI2qS knLQvWQjuNi4jR3PsKWMCaVCPhcjRXHHWemv+I//nkSmVVvZKSeCf6Ap1KSW2FXDRbpQ2M 319S/mKN2hTkOCB+K/O1FP60E4bAV8BXdacx0z1rPGHU5lGqIT+jAYBbNDslJBNFrKeTR0 vdXboL/tMNdePpEPr3auMO8F0wrlnwXvypc5JLq/0T6u6Yz4+FMXAVTfODtqAA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1763823738; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UJZ2NZoka7UCzKuTeBAXXE6vhBEjADNjFdksBoB0Etk=; b=TICwJsZk8EXiEYXGE60SChAVfADpTqd/g2Z29y2k82MPqSKnbhPersM2Kw8LEQwLthIlEl +T15weEbA9MlkUAw== To: Nathan Chancellor Cc: LKML , Peter Zijlstra , Gabriele Monaco , Mathieu Desnoyers , Michael Jeanson , Jens Axboe , "Paul E. McKenney" , "Gautham R. Shenoy" , Florian Weimer , Tim Chen , Yury Norov , Shrikanth Hegde Subject: Re: [patch V5 20/20] sched/mmcid: Switch over to the new mechanism In-Reply-To: <20251122004358.GB2682494@ax162> References: <20251119171016.815482037@linutronix.de> <20251119172550.280380631@linutronix.de> <20251122004358.GB2682494@ax162> Date: Sat, 22 Nov 2025 16:02:17 +0100 Message-ID: <873466jekm.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Fri, Nov 21 2025 at 17:43, Nathan Chancellor wrote: > Our CI started seeing a hang in QEMU after getting to userspace when > booting with a single CPU (our default logic when using TCG instead of > KVM) that I bisected to this change as commit 2635fb0f0973 > ("sched/mmcid: Switch over to the new mechanism") in -next. > > If I change '-smp 1' to '-smp 2', userspace runs properly. At the parent > change, this issue does not exist but it is obviously possible that this > change exposes a bug from earlier in the series, I did not test. Duh. Never tested with smp 1 :( Fix is below. Now let me stare at that num_possible_cpus() fallout. Thanks, tglx ---- Subject: sched/mmcid: Ensure that per CPU threshold is > 0 From: Thomas Gleixner Date: Sat, 22 Nov 2025 15:54:39 +0100 When num_possible_cpus() == 1 then the calculation for the threshold to switch back from per CPU mode to per task mode results in 0, which indicates that the per CPU mode is disabled. Ensure that the threshold is > 0 to prevent that. Fixes: 340af997d25d ("sched/mmcid: Provide CID ownership mode fixup functions") Reported-by: Nathan Chancellor Signed-off-by: Thomas Gleixner Closes: https://lore.kernel.org/all/20251122004358.GB2682494@ax162 --- kernel/sched/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -10364,7 +10364,8 @@ static inline unsigned int mm_cid_calc_p unsigned int opt_cids; opt_cids = min(mc->nr_cpus_allowed, mc->users); - return min(opt_cids - opt_cids / 4, num_possible_cpus() / 2); + /* Has to be at least 1 because 0 indicates PCPU mode off */ + return max(min(opt_cids - opt_cids / 4, num_possible_cpus() / 2), 1); } static bool mm_update_max_cids(struct mm_struct *mm)