From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 A276042E8DA for ; Thu, 2 Jul 2026 09:02:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782982925; cv=none; b=J7REbOwlhWbQCNwZ6F8hcD/vIG1A0KDlJy5BmcgWCkxmVTDDnfKmUo2Ttl4Z2g5DJD8iTHVxvFlh21EyNCT0T38eobvcKTErX7fW2jtYJPikoTe57nh9TdFYZMyNJ5ruy2sXnMIxh1WushPrspP5CIwJBMQnlo2q9tzq9kKCXEw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782982925; c=relaxed/simple; bh=B2yryFS1pzztv7ZW0K9wBrOjoBigRup5E4OTHDALeik=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lh8i/kxe0sCuJzYLaiuF4OqC1RbWZKEI5Cz43VEEAJe10ykq515vHL7+n1fSjTXrtmHByGDrTIHc9sruMPq/HTFucGpgXQMX6TTsZIcIG1AJNluRazKls2FOLaU+nHFHwHUJB6soSsxAoEtATOZVjabZJbi/f7Jsjp0HSXuV6b8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=aKX0AQG3; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="aKX0AQG3" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; 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=us9hGjvr31fzYBq9JNKSKNnSUFugtPDoRlqE/H4R2IQ=; b=aKX0AQG3xQ2DOUg8Zw0a7p1msH 83KgCtFi62P54izfjwCK5nFO4M5YMI00IE92OTkea3JXZMHvQZKdf9M5PcwIycFCYBEmqETS1Yqcm 9Seg2ln51TM2w/UJyJVJG7CmcpAUC2UKkKpQw5bFmbPW19Ft7zmh1xURupBQ+FEY/QodqvZ9I6kHZ p3e1M65Hc/a7dG0HOnDqj1cZrIMMX3dbPYV9xB3y3Pts6XjrxjLeM6mAH3cMh5wvdSoomKdAbLQpQ dJHr80qk84p7LQeoadEXiRgnKQXp1C7FIT44M6/ogTbAfzR8Wj+6VAu9IVr9QNnCz66pTfDmT7fw8 g90IQkfw==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux)) id 1wfDIg-00000003aUM-19tf; Thu, 02 Jul 2026 09:01:38 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id B52F7300402; Thu, 02 Jul 2026 11:01:36 +0200 (CEST) Date: Thu, 2 Jul 2026 11:01:36 +0200 From: Peter Zijlstra To: Vincent Guittot Cc: mingo@redhat.com, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, kprateek.nayak@amd.com, linux-kernel@vger.kernel.org, qyousef@layalina.io Subject: Re: [PATCH] sched/eevdf: Delayed dequeue task can't preempt Message-ID: <20260702090136.GE49951@noisy.programming.kicks-ass.net> References: <20260701164920.1571352-1-vincent.guittot@linaro.org> <20260702074304.GC49951@noisy.programming.kicks-ass.net> 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: On Thu, Jul 02, 2026 at 09:53:13AM +0200, Vincent Guittot wrote: > On Thu, 2 Jul 2026 at 09:43, Peter Zijlstra wrote: > > > > On Wed, Jul 01, 2026 at 06:49:20PM +0200, Vincent Guittot wrote: > > > Load balancing can migrate delayed dequeue tasks to even the load between > > > CPUs. > > > > > > sched_balance_rq() > > > -> detach_task() > > > -> deactivate_task(DEQUEUE_NOCLOCK) > > > -> set_task_cpu(dst_cpu) > > > > > > -> attach_task() > > > -> activate_task(ENQUEUE_NOCLOCK) > > > -> wakeup_preempt() > > > > > > A delayed task with shorter slice can be dequeued during pick_next_entity() > > > but then jump to preempt because eligible. > > > > Cute. > > > > Perhaps we can look at enqueue()'s place entity and determine > > eligibility there and complete the delayed dequeue there. But that's > > definitely something for after the holidays I suppose. > > > > I'll go stick it in tip/sched/core. > > Maybe better in tip/sched/urgent because of the warn triggered in set_next_buddy Hmm, but the Fixes tag you gave it reference a patch in sched/core; is that tag wrong? Or do I just need to imbibe more wakeup juice?