From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) (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 04AF13845B6 for ; Tue, 3 Mar 2026 06:30:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772519416; cv=none; b=fz8AiH7A/Bonm+dYED4C4FCtoJwj1dNIL7ZYYotUy8K/EfNzEatFD9oMgN/1AKNTF0V6u7jfJN3cE9/FyORcGZZzZF/v9eUr/GWksp/UECN1SDSqOhKqUBGuj0P7C61ADJ+uqLBXBTKsEMstSyLtY3xN2UW1wcwLsccoCh2zJoo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772519416; c=relaxed/simple; bh=g2JYU/txhln4Mz3DHN1pol4n5F2KsnK+9fAOhTNwvbQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dSzAECCShdcsfPTluk4++B3rVpu8AKZVABYydRX3K9vx6hA7fy/LStWQ5nzxfVWByyiv40IleGkWeKa/1JhyZ/6gCTQnvMlNdT0PjlIsaxL/XwmwvVlIXxTeIdwvoifCGIT5nbMn0wSaTiwbfL6RP67gLRTq4165FHVIpmvOFjg= 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=YQlkY+jj; arc=none smtp.client-ip=209.85.210.173 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="YQlkY+jj" Received: by mail-pf1-f173.google.com with SMTP id d2e1a72fcca58-827546f228aso3338402b3a.0 for ; Mon, 02 Mar 2026 22:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772519414; x=1773124214; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=3CX4pq1XdkNKJHtogOxsgo6tO5NhJmpKiDY6wQL+x9M=; b=YQlkY+jjmZ6oClaWI8izX0dU2KCqN8qQiZ+FZHou/9saxuXMLhvcbl7NMKDL/BB8lN 5VmXTROZnpVg+NGfS34JbqXrZHTa4vktLwZhUaSDN6n7POnN68ww6VRHsb4n0MemXGF5 nOKY/+vcsCeDAg0Tb/PM62MfWA784GNmLkP3elHcw23oEEY1flvCHDbztyYo6/+tqOey /EAOH+XBGkvgN+VH+OvUdroryGhAmfW+FoIjzcq8LQjME17KFAq509PV434UjrYIgtTg zulGiJqjdpDJvhLam8dDJMXeUTJhwCNwFBSLpHax1HkNLYFWw8lht9xxCaEIT6UXJfsW SZRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772519414; x=1773124214; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=3CX4pq1XdkNKJHtogOxsgo6tO5NhJmpKiDY6wQL+x9M=; b=uOGI6fMV0+ZHT8YDvz2qp/cXv5qv6pRG+8XZADn8GPVxx3jw8Twv2bPgWcNxQxuR8O 2Slx6kDx2vbaIugRW38CeXo0Fa2f7uIwd4mFQ5+7lNUYdpSRPMkPBLxOrbSIo6wruA80 7RmvBTcNld/Mu2c27Y+HY3ojPw4rPxNgxe2eT6OKz6hoycAe/NvLYjJphPLQ4pAh5325 cRx3wREttKSi3cWSaX1baFbMXbj6ID2G6Zl5STtSuwgXKjYaLScyIAMI3GLDsT+cpoDQ NhbrtM8MaDLh2N3sd1ZcLSrIKpnjkrr3b0KgPnjWjiyyxr8OwSCjYqPt1EnEFmBmdkfd Ae9g== X-Forwarded-Encrypted: i=1; AJvYcCVH2ZlNtEDW7QY4fW2RQK5I5O8BFm4a/fW/ZelcGBcWDTzqlnrgIYabHHurqT8o6kRoeq0QuYGYrRRfb1E=@vger.kernel.org X-Gm-Message-State: AOJu0YzWNCGBi0JSpZhhIM/tmF5qG56UidXCvIXyIQXqT/Q4dnXi2Onh pa6yOC1c0GC6qObdMYoOEr5KwVZ/LI/VAdzLMEnwDf5MnGrRUjN4Ii7R7yEMUetb X-Gm-Gg: ATEYQzzu4CTmVnnrzyfQPWi/UYvT21Zdc3W4pe47LB8gzzRgKgl/ZkcZ7HRqHcLN74U mHQmq+4y7uM+57diaUDNJxkD1t+GkWqYoQ+cfd72gkkm5HfhzMhFgDJeC6eS0sSYmSrkLoVKOx1 K6S4YNcTMczGLDoCxJJaATzNvzMhWhpDbYvXvQ1/GxSeeJLJPtCXGCRYgSUaG936HDZ08lCG58h jMPbs0Ljsm9HfJqK5xIhRT9QtRvaZXeMv3D/oqQUfS36H+QH7eSNmEavnZCFvhg36I1AjbOTGA6 DVAUIh/+qwkqJGZYAgN21tDsBKyQIGT5uOZI+X5RfXaNz8RdphHAUKgocKs7GGluChnGrzA2WWb EhAPTvfUxGOYpW+FEORWJgyd+cV746JjEYVtnZHBtbqmRdgaIJwoDxncsYZFzxQRBbRely0Pcz8 uyMj+X5xZa6h4m+DpX/R3p0/BEXXn4wOQdsowYdvw+E6ZPhdvZRnG9TaWmjjf719Rw9G68Iv4wM lQ7 X-Received: by 2002:a05:6a00:9506:b0:824:b024:93dc with SMTP id d2e1a72fcca58-8274d9f446dmr17094132b3a.35.1772519414288; Mon, 02 Mar 2026 22:30:14 -0800 (PST) Received: from mi-HP-ProDesk-680-G6-PCI-Microtower-PC.mioffice.cn ([43.224.245.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8293c29add8sm7608366b3a.19.2026.03.02.22.30.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Mar 2026 22:30:13 -0800 (PST) From: soolaugust@gmail.com To: K Prateek Nayak Cc: zhidao su , soolaugust@gmail.com, linux-kernel@vger.kernel.org, John Stultz , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider Subject: Re: [PATCH] sched/proxy_exec: Handle sched_delayed owner in find_proxy_task() Date: Tue, 3 Mar 2026 14:30:07 +0800 Message-ID: <20260303063007.125383-1-soolaugust@gmail.com> In-Reply-To: References: <20260302101235.3988601-1-soolaugust@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: zhidao su On 3/3/2026 11:29 AM, K Prateek Nayak wrote: > Just switching to idle will not alter the EEVDF state and the pick > will still converge on the same task whose owner will still be > delayed. > > [...] > ... And the cycle repeats with preemption disabled !!! > > This is terrible since blocked owner can be delayed on a busy runqueue > for more than a few tick - sure it is a transient state but it can last > for a while depending on the state of the cfs_rq where it is delayed, > up to few 10s of milliseconds in a practical worst case scenario. Agreed - the spinloop analysis is correct. pick_next_task() keeps returning the same blocked donor; proxy_resched_idle() bounces off idle each cycle until sched_delayed clears. Tens of milliseconds of that is clearly unacceptable. > proxy_deactivate() is correct to do for now until we get to the > blocked owner handling. Right. I'll send a v2 that keeps the two checks as separate blocks (the conceptual distinction is worth preserving for when the blocked- owner series lands), but uses proxy_deactivate() for both: if (!READ_ONCE(owner->on_rq)) { return proxy_deactivate(rq, donor); } if (owner->se.sched_delayed) { /* * Owner is in EEVDF deferred-dequeue: still physically on * the runqueue but has called schedule(). A sched_delayed * task never has blocked_on set, so the chain cannot be * followed further. Deactivate the donor for now; proper * handling will come with the blocked-owner series. * * XXX: Don't handle sched_delayed owners yet. */ return proxy_deactivate(rq, donor); } The comment replaces the shared "XXX" with per-case rationale, making it clearer why they are handled differently once proper support lands. Does that work, or would you prefer the two conditions be collapsed back into one?