From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 06A2532FA30 for ; Thu, 30 Apr 2026 06:16:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777529769; cv=none; b=Mh6Lv+6ZCaPEguG9kVUBCTG7IFJ3EnhIh1jFSgGXokFE6DcyYosceXg4xq5WVQ+8CDAMJPhf8JWdR8EtblZZ1ar7XmcTejf8SEeLtfNiTDFI7dtwr68/7U+KnS6ZKvF6O6Afefyxvj4f2QEHr6i500qnviJBTOoHQe2m7fAMf38= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777529769; c=relaxed/simple; bh=w3K5SjXdrpPZSgHVyFxDbMBO2wEjxcnl4TpvgVagRw8=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=ObTQqfwJFNiP5kedbxRVY1jYCqYNY7f5Equk6EruxzAKOakA7hzrk443k3uoL+b6sQWtJ/KxZ2Y5K1iaMOUFnhMibDidggVJWe1Omg+OiGZuB3XjDNUPROKk10u+1OnJ72lrTns9QyZr0/stUvsRgplaKSEEui08RNmVVP31xNo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=qiyH98dQ; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qiyH98dQ" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4890d945eb4so9443565e9.0 for ; Wed, 29 Apr 2026 23:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777529766; x=1778134566; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=vYZ5aaFCcpLZ9tON0lfpFRw1zBnsyjzYWEgNF/FBIss=; b=qiyH98dQefd3fFh33UEm474tD9lOrdBcbfLubRyYV2HEXX9OaKABQuHllTOl7jmBZc 1W2rBi2kIxKtBaEo8GBhMDMUHO05KYPX9IitWUmS51n6Sgh/E3sNn+LionjCQpkVShcu P+VoDcqCIhei55pt07MbEQVb9HfnNu4CJ54BAl1DKSiJqdnRYzFWxg+3Cz2GnBmAzIpF /7Qman4WVhO/cMoXiKnCFQwaxQJ4X45RSFP2GAgp4ZrHWTk8gztDGbdPWPw15sfY9wxm BffdwIF6hve+voaoOO6IxutQn7Fr4HpuxJDZXfQFXLu8YBVOG1dl+rDRYDiKXmmnwXi+ Bu8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777529766; x=1778134566; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vYZ5aaFCcpLZ9tON0lfpFRw1zBnsyjzYWEgNF/FBIss=; b=lOESN4i0lWPH6kYMxGlHoJvqFF3hXIlLtQey2lYr/T2UOds+/u+oGDgul4xX5NTvFT AiyEkDsDh486knZj3slva8koNyHMeyOtd/w0ltrVFnfBnj7vSm2ZliiUghTqPq4EE1BI zOJH+hFd/FgGgPqpcS2e+IjHDgLaVxoeot/tfba3Ht9AlLixo8jEhJ7k7OBvubmtJqwh Llg94ymHQ8zmDrK30f0q83+3AT27z2VuQ/0UploVmAZQAXv4qTmXdFnq+IuhX31O8S1x r91CbHhSjAAF/e3xvYTZRDLxCaB2+FN6SZQUc5jptDSwDJMyurjZxrwwxJK1W3HQh/nW c+0Q== X-Forwarded-Encrypted: i=1; AFNElJ9puHKdtN8bgDF5+SOrNR4172iOE3peWVzSv0CmVQsYJ7vTZvzMld6uQ99hAtbVeWz/HUBSxOVyWcgh6b8=@vger.kernel.org X-Gm-Message-State: AOJu0Yyrw29iQWs4Tny4ug27Kl1RkDmDqcGPJ/DEpz8zXsDiGDzKIQNL 5FQ1YUb+oaCDkCU6IO1dEYfk+oLTwHWfPI1UXyzUvc09iV9eF6c531FX X-Gm-Gg: AeBDievu1subl6mrGqq/d+nvhTw/YTgLVhBaDuMcnWMzLZANMQdCq/wcVGTZvYYQPGK lu+k+ni2JtIVI0Q13XQtVp/ocmA10Y8nbZ1xHBsann3Bh3gUqk+l7Ys1p4tYmN2JnezlVZIePGH DAsISuYXiM0smvVTJIc0jCxLsyIQI9G5uoeBwnN1RvxyBXHC3TwroRBb7P+qhkjPYEyQQPCg6N1 iWocxl0YJamFtQQ/JWy6Q4ysLmpcI9l0d5SLOCtFZU0+teduaErjfRSw+KtBaEGwL+mjSLg4O9B aMHB+H1Sz/bmwV/HzTqnzhsZg6dCyPrQYTw93EVhYvZChK4OwbFiJCVVr9+GDI+wriIq88Wa1vG B2xuDssU8jqqrJ0q2TZMIwvFI/8varCvKX5XVAMLUm8MgCpD7VuEopUoxgagGEp1lEJPnjRDxTy 4DjHUm2REQYsVyFYe5bI52fq2felojGTPMEGW4jG2JePF3QHgPvt2s X-Received: by 2002:a05:600d:8449:b0:485:3cef:d6ea with SMTP id 5b1f17b1804b1-48a8609892bmr12402965e9.13.1777529766211; Wed, 29 Apr 2026 23:16:06 -0700 (PDT) Received: from [192.168.1.109] ([85.107.100.155]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48a820c71c8sm71379405e9.4.2026.04.29.23.16.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Apr 2026 23:16:05 -0700 (PDT) Message-ID: Date: Thu, 30 Apr 2026 09:16:02 +0300 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] sched/fair: Fix wakeup_preempt_fair for not waking up task To: Vincent Guittot , mingo@redhat.com, peterz@infradead.org, 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 References: <20260429164102.1388139-1-vincent.guittot@linaro.org> Content-Language: en-US From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= In-Reply-To: <20260429164102.1388139-1-vincent.guittot@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Vincent, On 4/29/26 19:41, Vincent Guittot wrote: > The assumption that p is always enqueued and not delayed, is only true for > wakeup. If p was moved while sched_delayed, pick_next_entity will dequeue > it during the attach and the cfs might become empty. > > Fixes: ac8e69e69363 ("sched/fair: Fix wakeup_preempt_fair() vs delayed dequeue") > Signed-off-by: Vincent Guittot > --- > > I have triggered this while running my latency stress test on a new platform. > > kernel/sched/fair.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 728965851842..99fb524c4922 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -9147,7 +9147,7 @@ static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_f > * Because p is enqueued, nse being null can only mean that we > * dequeued a delayed task. > */ > - if (!nse) > + if (!nse && (wake_flags & WF_TTWU)) > goto pick; > > if (sched_feat(RUN_TO_PARITY)) When a sched_delayed task is migrated (which can only happen via MIGRATE_LOAD per can_migrate_task()), enqueuing it on the dest cpu will call wakeup_preempt_fair immediately, and if the dest cpu is not busy, pick_next_entity() will likely pick and dequeue it immediately. So a wasted enqueue+dequeue pair. Could we skip the enqueue when sched_delayed is set, and defer it to the actual wakeup path? Thanks