From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from MW6PR02CU001.outbound.protection.outlook.com (mail-westus2azon11012014.outbound.protection.outlook.com [52.101.48.14]) (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 9AEE4430BAA for ; Tue, 3 Mar 2026 15:40:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.48.14 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772552421; cv=fail; b=DAhEWabgBhWLVXBW9umzYVmwzAD84xCXvZK/mpKZu4ZLl1i2PgsfWvaukx9vPUAVGnlEBsEVkbWaG6WbupO4FR77B9sIu6aPlq5oSWOgbmEHdrF8ST6O0l8+PS8RTp4S/eHEMukRcebUtbusSO77bizIpy6P+2+zX1RMtlTeW7o= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772552421; c=relaxed/simple; bh=IsmcIMVE7FW+smMlreAAirsuECGIrIpnCP+k2nI2xYo=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=hFyTVIx1pSceNiKZzC20NeVSPEQJ7cQTywx7Abkb5axOa4kSK39jIzl5cOBNp4kn+IoxmompORyXRlTT131J7nfTYrUMbVitBTRjeKvWLgEyKF8zhUpJwoAtPF+wrXw0Z92ew2w0Uma3OkFHcFRuUvWN3cLt7khcQHDR7fuM/IA= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=FaUJaDZM; arc=fail smtp.client-ip=52.101.48.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="FaUJaDZM" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mzIrQWFlwJQTOkKm6i6dD1yTaJablzLTvslcCJQK1zPRmp9zAUhDULqE4UqsFZ5N3wOGoPgxKPhd7Ec1kT+Bij+VqAxfSuMaoWA0VB7fujNrUOcupJLUqWvVFousvl9CaCszz199j1asKaX43w5NtCdE6BRE9wRYlBnXstzfvDYYlWZKEBz5Z7XvS1v2PKaVMGv3AyB5kM5JhDohGBMCVdAMdKo/XaCl3noHhNrK1mwRM08odrPz/XUsP+wiOf+6wTyNL2ui3yZXteFckNvVmE2oATd8IAm5C8ePNREzv4MpaEvug4xXtPSvn0lkpyM1wmblGDiUjB5hwDzeWrB4Lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4/ItN1nT/Nva7sNcFqjS+jZT3HbYVm9aa1tJW8m7kI8=; b=e24e4G6ngrfZVn0/Af5t2fv6Ku52mRI3TW1ooC92AMf/eQ+AhhnrxtQFdMvsV9efpxQiWK1S/qiPsEPHMrap5vgaHUCZau6bsiZbrwLF7iKylea6WstZE1tiXQcklG9yyrC8kEYrCtGpGpW4eTD8c1dCJ/LpFMPWvB+nWp0igBfmZ+Z8EEpiM3O4sfMdeEUQqzTbimJVLB4RA5SKg5TCluEXoMvH1iJnsab0DcEnR8bfKIYeiWe7sOf2Ert9sIuaGePFxk/mdEm5UV7aOfJOAGc9j53TTIhiqIu5JHkxbvAm41OmOU4k+ekuEXkZrcZdeYIRRIJgl8NOv4ATf8khkg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4/ItN1nT/Nva7sNcFqjS+jZT3HbYVm9aa1tJW8m7kI8=; b=FaUJaDZMLLn8g8APwkicnaZvM4HnKCpDepmUFtDLPXKGQuN94KiR44c6pwYsyivLAknnV6tcosOj2k9jqRgLQxcXqKpboUl+f5+h6MWmHWe9w1PIW3H7FEck3ODzfpBp9l/vc1c7Gvoz9EjRsuYYqDYxsGaFUX4NpdcJFnd9LdY= Received: from MN2PR15CA0032.namprd15.prod.outlook.com (2603:10b6:208:1b4::45) by SA5PPFE3F7EF2AE.namprd12.prod.outlook.com (2603:10b6:80f:fc04::8e6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Tue, 3 Mar 2026 15:40:10 +0000 Received: from BL6PEPF0001AB73.namprd02.prod.outlook.com (2603:10b6:208:1b4:cafe::14) by MN2PR15CA0032.outlook.office365.com (2603:10b6:208:1b4::45) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.21 via Frontend Transport; Tue, 3 Mar 2026 15:40:09 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB73.mail.protection.outlook.com (10.167.242.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9632.12 via Frontend Transport; Tue, 3 Mar 2026 15:40:09 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Tue, 3 Mar 2026 09:40:06 -0600 Received: from satlexmb07.amd.com (10.181.42.216) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 3 Mar 2026 09:40:06 -0600 Received: from [172.31.184.125] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Tue, 3 Mar 2026 09:40:03 -0600 Message-ID: Date: Tue, 3 Mar 2026 21:10:02 +0530 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/proxy_exec: Optimize proxy_tag_curr() pushable removal To: , CC: , , , , , , , , , , zhidao su References: <20260303115718.278608-1-soolaugust@gmail.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <20260303115718.278608-1-soolaugust@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB03.amd.com: kprateek.nayak@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB73:EE_|SA5PPFE3F7EF2AE:EE_ X-MS-Office365-Filtering-Correlation-Id: a210fa72-b800-43a8-7948-08de793b271e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|82310400026|7416014|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: 7wmS9MumsCidqyRoMwGOCAoGyB4gPiTiox46a5xIE0Bdg1LPFlY3YlOCZvWahXvWvOIsiQouzT7TPCV5XBTlyG67TzXrx1m3xjz/U6j0FG0RAsnfsZkr582ra2RWVZXc4GweilvmWEKr6+5WeDQSQ+adpRwiKw3qEk4cJ2zhCuX+MtQGmqc7G5m9/33YtRugZfPbMHbnlrfLHK/NAbAMz8fpPOKSIs9OjuGJAB050gK/mlfBTFhrqrh5CPmi8DxQGhP9YYSEFN8HNomGFfTMQLBy91iwJ6L5c2RJu5k3HHX75BgSSBspnmAEM2khQZcgXCkcGchhjzl55yFrqFKvFLf2opoSaGEN88zo9RzBICNtWCZ5BZTBvxhuHvMYQIYKFx+wnmDYc667erVR36S1TNpX6fr4XpuQHYjEkh78F9FzZavV9f06YSHP/DmP7niaPALs/jlpPp030yq33TMWbGv2/o7JUTQmAqtgzmch0MuoCfveU1Z7+aU+kC2XKm13uf+7IHLLavl+7kNlbiv8BGgXT3kbtTx5st8Ag7zFATh0Bm57Eq1/7yYRzMtjPI+wN5ZOgYuKWHnPvaiJXd417TPQhA6IH31qdogd/TGsMNOqina8rgI8uOpWCYsSRorwIa+lCjPhot9hpIPkvlkenyLTUTv73elZm7Bjy6Pfh+c9W94hP1sNzRg3aYHvBVJ0LizvV0562iovDkzWODDV3YQv4EWUuNc3QPYuFTm8DL4Te2CLHZuyMysJvGYvZP1VYpsCHogX0b6VqmyPhgrzQfBZCxpc6GZNoF5B4cY+vHC7nByc+QLVO9VNzPRn+zaiIRb0pfZj9fvqdk0NUTy+/Q== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(7416014)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: MvPg3PnzDsOJdcifqJKxqjz3WLjfQgVFoMeKii/mE0gtEjIqrPKiD5jVCTgWQZR6aPlpdJLIPY6z7pY+2jxu8ayn+suc4SCeFxs1ByzncImnA0cVlO254HRkGmy5ez/aLMIFIkvwHqfkpNHEjSL5mPKMNWtaApXdln3esbDz59aTtcSI9+TbXKL7bfoBiCVeEHfHZJVJEJzMP73qhL6zXZNnfmKLPL/+OZj7CGtd1xANNgCcj9HEuzzHdAjLL6nirRLaw5EFfgaxuGBPx6FMKAzYWqZHTx6iAtTcKyuF2i5hGDp7UvKmp5JKyFNKd0g/8RTO7Hb7wTKpwPUARSkCoo6aP9xtiafGV/voznY1XWbp1U2UlJLkOo6VMFgHXVY1o28WBzZBwXCzvBgvW8moSgPWBa4xmIT/o96SiWQG8ioY9IVP+dvxQe6rF8rwuhs1 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2026 15:40:09.9091 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a210fa72-b800-43a8-7948-08de793b271e X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL6PEPF0001AB73.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA5PPFE3F7EF2AE Hello Zhidao, On 3/3/2026 5:27 PM, soolaugust@gmail.com wrote: > The SAVE/RESTORE cycle achieves pushable removal only indirectly: > enqueue_task_rt/dl() suppresses re-enqueue into the pushable > list when task_is_blocked(owner) is true. The same result is > obtained more directly by calling dequeue_pushable_task() or > dequeue_pushable_dl_task() once, without any of the side effects. > > Replace the workaround with per-class direct calls: I had this question in the past and from my reading, I think we can safely call the dequeue_pushable*() helper (John might have some notes on these bits) but that direct call is just horrible! Why can't we just have a sched_class->proxy_tag_curr(rq, p) or such and just call it if a "sched_class" populates it? > > RT: dequeue_pushable_task(rq, owner) -- O(1) plist remove > DL: dequeue_pushable_dl_task(rq, owner) -- O(log n) rb_erase, > but avoids the bandwidth counter churn entirely > CFS: no-op (no pushable list; task_is_blocked() suffices) > > Both functions are promoted from static and declared in sched.h. > deadline.c also gains the missing isolation.h include required > by dl_get_task_effective_cpus(). > > Signed-off-by: zhidao su > --- > kernel/sched/core.c | 28 +++++++++++++++++++--------- > kernel/sched/deadline.c | 3 ++- > kernel/sched/rt.c | 2 +- > kernel/sched/sched.h | 2 ++ > 4 files changed, 24 insertions(+), 11 deletions(-) > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index dc9f17b35e4..2aba15d84b7 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -6728,16 +6728,26 @@ static inline void proxy_tag_curr(struct rq *rq, struct task_struct *owner) > if (!sched_proxy_exec()) > return; > /* > - * pick_next_task() calls set_next_task() on the chosen task > - * at some point, which ensures it is not push/pullable. > - * However, the chosen/donor task *and* the mutex owner form an > - * atomic pair wrt push/pull. > + * The donor goes through set_next_task() which calls > + * dequeue_pushable_task() making it non-pushable. The owner > + * does not go through that path, so we must remove it from > + * the pushable list explicitly. > * > - * Make sure owner we run is not pushable. Unfortunately we can > - * only deal with that by means of a dequeue/enqueue cycle. :-/ > - */ > - dequeue_task(rq, owner, DEQUEUE_NOCLOCK | DEQUEUE_SAVE); > - enqueue_task(rq, owner, ENQUEUE_NOCLOCK | ENQUEUE_RESTORE); > + * For RT tasks: remove from the plist directly. > + * For DL tasks: remove from the rb-tree directly. > + * For CFS tasks: no pushable list exists; can_migrate_task() > + * already rejects blocked owners via task_is_blocked(). Tag is for the current running context (owwner). task_on_cpu() check is what guards that for fair. > + * > + * The prior dequeue/enqueue(SAVE/RESTORE) cycle achieved the > + * same result by relying on task_is_blocked() suppressing the > + * re-enqueue into the pushable list, but it carried O(log n) > + * overhead and, for DL owners, triggered sub_running_bw() + > + * sub_rq_bw() -- bandwidth counter churn with no net effect. > + */ > + if (rt_task(owner)) > + dequeue_pushable_task(rq, owner); > + else if (dl_task(owner)) > + dequeue_pushable_dl_task(rq, owner); I think a sched_class callback would be better and it'll also allow other sched classes to just populate it when need arises instead of adding more else if here. Like: if (p->sched_class->proxy_tag_curr) /* or dequeue_pushable_task()? */ p->sched_class->proxy_tag_curr(rq, p); Also I forgot how the current context gets put back on the pushable list once the proxy is done since at that point it is just a preempted task on the CPU. John, do you remember how this happens? I think we might also need a proxy_untag_current() which calls into enqueue_pushable.*_task() which does the minimal bits of put_prev_task() undoing the tag and possibly queuing some balance callbacks which would have been skipped by set_next_task() on not seeing any pushable tasks at the time of donor pick? > } > > /* -- Thanks and Regards, Prateek