From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (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 A75A83A7F64 for ; Wed, 15 Jul 2026 02:37:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784083056; cv=none; b=HjJUgywkMWqIuTAw0m9Cv2GA5sAfMDinUYBSu9BoREf2UgQzS6qOcQ3R1UZqmyZd6lGEemtcSQ24nzDoe0NkSx/rJUwOuXgkbuQR87CpADHRQlxKJdHn65EYeanVA4GFyykDAl8W7XI0XjTFOBjFj7USK22YO0pFQrG6sNiKpUg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784083056; c=relaxed/simple; bh=DXiIBHuG/O4wXAqEey9avfaeo6U80JirIN6LA+CMu4k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: Content-Type:MIME-Version; b=Sqzs2fr+5PEleITm/O5UGG6vDPnfIc5NSYLbajTWGkv8MIo4sEULb963X3IPBr77s3JKlbauMU0cN3Pb76q2fnzhdsTSf6zK7AODbAPptsUZpZaEpdJEVd7Pn2sXde1DwEEaqVhyi+UrrWEc0JEq1CQZUp8m0gB3epGnPlAizog= 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=admvuHYP; arc=none smtp.client-ip=209.85.214.174 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="admvuHYP" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2ceb096e675so39999115ad.0 for ; Tue, 14 Jul 2026 19:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784083054; x=1784687854; darn=vger.kernel.org; h=mime-version:content-transfer-encoding:content-type:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=DXiIBHuG/O4wXAqEey9avfaeo6U80JirIN6LA+CMu4k=; b=admvuHYPjQxmuuVu1y7xu/KgvLM6y7LbBe+Qr1yU1A6wcsCK5nJj3SjVNVlRYC07+D 19Uqab9rPHiZ3wld4YqE6H3VkxXZgDm0z7RMch28EhbeKf+j4xejCqgid0UGe2G4W3hY znrSDQJ5euS9TD+CTej90AGzqSIWBQ5TvScn+q0dms5KZOE0pA2Ps0Knv8XE1THy+st2 Xz+ZioDdlDgrA/gJeRJKvwk6dlZEMdyA+Q75ZftnqIa+byW31lOufjOrqqBZaJr4fGBI 73ySooq72QpI8E9KzILZLez6gakQY2LhrNiNxAbva83lCOEumdT3FI0xhSmFHkbxnlJ1 7PVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784083054; x=1784687854; h=mime-version:content-transfer-encoding:content-type:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=DXiIBHuG/O4wXAqEey9avfaeo6U80JirIN6LA+CMu4k=; b=T64sfIl0SabPQNdJh/OM2UTUhS5NP2vDJsiu/ZqZS8WQu5GoPX+6GW2DMloU+lMCiU gAE7Eg62Y4tLPmNARQieBsk2jtgv8JDFddwlmTQdHmIqDzrhR7+KIBVXfv3dhYNwrGxF q3hNryNkGqUNyIGrrRAV4AD0mB66FSmKgXg24mrLg4l1n1OCOq9Lpf4xy/Akaw0wCgJR m+kv/B4H9JcT3DE+qsOSaqdps7lELkjTlJFglW+49iWa9prjUPoXqS/vfxvFFhliZxn5 gwEEvbx5FSoUNXoLb1ioBCY6ES6H3OAyBkfLe5pid/qLE9RGx58k0x6Kst6Yc6n6gjHI 10Ng== X-Forwarded-Encrypted: i=1; AHgh+RpQvM4kbx2aSXrFd/i6mRGA4TsrtWvNaSiNZjq5SsrQVJuPpWMp6WuMcvjBx2fgNPQHPABTPo/0HXxFEeM=@vger.kernel.org X-Gm-Message-State: AOJu0YydIY7yegxpXiCc1k/iIQA9C+9OMCL+tBDIt/Iaf1pRSzrLJQfu mA4Rc4cpU1XSaCHr1UaH2ImRKy/GXM4Df7RlkkJr0xfmO9jx6UTqDzer X-Gm-Gg: AfdE7cnWCU9Gr32dK1S7Mh2yV6ziHHGXcYhEQFSC8tXUJS+MKGfnQlvyJ0eE0Jm7NG2 gUurNYRGziLYqFDErhKQRZQMKT1c+guARHkIViKcMHQUaVQpFIK6ge6UTl8Kg1EUg1tELiWKybw /GJcTrWcOYi5/rHlWwQV0XkdhWUH9eMbnx0JmPPfMy8zlQYtJ5CJeiWcSpfIQrpMwELjrHf4HW6 cOCLV1HlSeTIHIwQ1yZfAaGoidPAnIa5oCA9fyuYJslXk/bW6r88MFF0/rzbG6WNn4tXGK5/6pc MdfJy3A2B+snIYVYsqbN0GC/1QdATQtuEAuUlRQzunp1cz+78+vHZfJUHN5t0WIdjvHTRLhM6oB cQEtgyRxuo6F0unUJ/tWXTvLggMC8voKgQrZJQxiMfH5GVF8c/R/0l1YqnPV6ojGxb+ryL25gDP LyGhBstPxmzic4ZA== X-Received: by 2002:a17:902:db02:b0:2ca:d172:7228 with SMTP id d9443c01a7336-2cf03c0fcb6mr9140075ad.11.1784083053878; Tue, 14 Jul 2026 19:37:33 -0700 (PDT) Received: from [127.0.1.1] ([43.224.245.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ccc9bdb76asm129110655ad.12.2026.07.14.19.37.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2026 19:37:33 -0700 (PDT) From: soolaugust@gmail.com To: K Prateek Nayak , John Stultz Cc: Peter Zijlstra , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] sched/proxy_exec: Break cyclic proxy chains by deactivating blocked tasks In-Reply-To: <20260714152220.4046736-1-soolaugust@gmail.com> References: <1df0e505-add4-4b7d-8e09-bc52402da617@amd.com> <20260714152220.4046736-1-soolaugust@gmail.com> Date: Wed, 15 Jul 2026 10:37:27 +0800 Message-ID: <178408304702.304643.2084630008424110320@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Thanks Prateek. > I'm not really a fan of the arbitrary MAX_PROXY_CHAIN_DEPTH. Agreed. It was only a guard rail, not a real fix. I'll drop it in v3 and switch to a proper cycle check. > This only catches cycles that come back to the original donor. Right. The owner == donor check only catches cycles that include the original donor, so it misses loops in the middle of the chain, like your A -> B -> C -> D -> B example. > Maybe we can use the blocked_donor backlink as a visited marker? The basic idea makes sense, but I'd rather not overload blocked_donor. That field is already the donor-stack backlink, and keeping it as a plain task pointer seems easier to reason about as the proxy-exec model grows to more primitives. So for v3 I'll likely use an explicit per-pick seq marker instead. > We should probably think about other lock types too. Yes, agreed. That's another reason to keep this at the proxy wait-for-chain level rather than make it mutex-specific. The current tree still only has mutex-backed blocked_on, but the design is meant to cover other blocking primitives as well. Thanks for the review. I'll rework v3 accordingly.