From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 542913C0C for ; Mon, 2 Feb 2026 12:49:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770036565; cv=none; b=fnYNDSEhUbhE5QCgTmxsiJzRQ5w+rJ09nRB86DJ/sWG4eHph3SGXbdOBR5ElJ3oAdbTIVW692gGNLJhvs/drj5x4ERVzThtfZnBbVR79LL2KsY/8LFzAKTHhQFtOvyIfPsCceyNVFIaPAcEHpMzyqocc0LbMFWbpCSqjCZTCric= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770036565; c=relaxed/simple; bh=A5bzMNTY2p/8FaEhY/+Xf5Navc5fVys8e92Q3gHAj9c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KGE1JuRsQBP7TRHk2Ohf+KSyv92did7guPHRtLNgmao7EH5th/ZP9K72E8WYmDY4oBvN9PERFIc/7igO2Tbh8HMXUccRudDL0M2+Nz/IthYKSGEr/VT2V1BqK4VsoEjCTxp9o1J/dUmn0oEXf+EAkdokKKLg2jW1tXQlnj+VOM4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=s07INjs6; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="s07INjs6" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=oLkbTgpJS9EDe+92MWDCuKjfu4gZ8/p8VaIVXiupiNI=; b=s07INjs6cg6D7uWtWtU+A4mi1n B91IH7wXo1NApx5e4UQFWgyEQWinzOc2nMYYb+T5ttNz8zT4lX/lOs33ZnDJkrMLYUUU1yvx7TdlC PkIfkcPelvE03F7zI4EVaUss5gomGhlH5gH2LAem0ATVKrJdEn1iQVGRaNYTNACYjHq2LomQBFHtY bfDMMFu1slY3CUJs2WRDPXQDDmKZ1mZcfPCG1LQ5fZGzIGJ+6DQJmHFSWkblj2giBMGJkmzyqFTxs UAyqwkhYQvlVBybfTKEO5ouTxJlvhlPfpfBI/QhG2uL20mqPzfs4y+Fj8z8FtCKPgHaHaTjQF9O3S BWFtDzmg==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vmtMZ-0000000GV2s-0C2y; Mon, 02 Feb 2026 12:49:07 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 61948300208; Mon, 02 Feb 2026 13:49:05 +0100 (CET) Date: Mon, 2 Feb 2026 13:49:05 +0100 From: Peter Zijlstra To: Zicheng Qu Cc: kprateek.nayak@amd.com, ziqianlu@bytedance.com, bsegall@google.com, dhaval@linux.vnet.ibm.com, dietmar.eggemann@arm.com, juri.lelli@redhat.com, linux-kernel@vger.kernel.org, mgorman@suse.de, mingo@redhat.com, rostedt@goodmis.org, tanghui20@huawei.com, vatsa@linux.vnet.ibm.com, vincent.guittot@linaro.org, vschneid@redhat.com, zhangqiao22@huawei.com Subject: Re: [PATCH] sched: Re-evaluate scheduling when migrating queued tasks out of throttled cgroups Message-ID: <20260202124905.GA1395266@noisy.programming.kicks-ass.net> References: <20260120032549.186733-1-quzicheng@huawei.com> <20260130083438.1122457-1-quzicheng@huawei.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=us-ascii Content-Disposition: inline In-Reply-To: <20260130083438.1122457-1-quzicheng@huawei.com> On Fri, Jan 30, 2026 at 08:34:38AM +0000, Zicheng Qu wrote: > Consider the following sequence on a CPU configured with nohz_full: > > 1) A task P runs in cgroup A, and cgroup A becomes throttled due to CFS > bandwidth control. The gse (cgroup A) where the task P attached is > dequeued and the CPU switches to idle. > > 2) Before cgroup A is unthrottled, task P is migrated from cgroup A to > another cgroup B (not throttled). > > During sched_move_task(), the task P is observed as queued but not > running, and therefore no resched_curr() is triggered. > > 3) Since the CPU is nohz_full, it remains in do_idle() waiting for an > explicit scheduling event, i.e., resched_curr(). > > 4) For kernel <= 5.10: Later, cgroup A is unthrottled. However, the task > P has already been migrated out of cgroup A, so unthrottle_cfs_rq() > may observe load_weight == 0 and return early without resched_curr() > called. For kernel >= 6.6: The unthrottling path normally triggers > `resched_curr()` almost cases even when no runnable tasks remain in the > unthrottled cgroup, preventing the idle stall described above. However, > if cgroup A is removed before it gets unthrottled, the unthrottling path > for cgroup A is never executed. In a result, no `resched_curr()` can be > called. > > 5) At this point, the task P is runnable in cgroup B (not throttled), but > the CPU remains in do_idle() with no pending reschedule point. The > system stays in this state until an unrelated event (e.g. a new task > wakeup or any cases) that can trigger a resched_curr() breaks the > nohz_full idle state, and then the task P finally gets scheduled. > > The root cause is that sched_move_task() may classify the task as only > queued, not running, and therefore fails to trigger a resched_curr(), > while the later unthrottling path no longer has visibility of the > migrated task. > > Preserve the existing behavior for running tasks by issuing > resched_curr(), and explicitly invoke check_preempt_curr() for tasks > that were queued at the time of migration. This ensures that runnable > tasks are reconsidered for scheduling even when nohz_full suppresses > periodic ticks. > > Fixes: 29f59db3a74b ("sched: group-scheduler core") > Signed-off-by: Zicheng Qu > Reviewed-by: K Prateek Nayak > Reviewed-by: Aaron Lu Yes, that makes sense. Thanks!