From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (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 36CF1431E7C for ; Wed, 1 Jul 2026 21:46:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782942380; cv=none; b=a9yIIOVzLO4OtaCciywoI8/louTjyEERfxTT0EfSZwa1VTlI1QlBX581gZ36pRDKXhlAcfz203VkV3OLI8ttKyT8TKcSMpqj2XyFbakAycwQzDTPxFrehOyPUjnTk7KXDlWTpy5IzD4tQ8jqSJcr7aS3oolxFN1VOnKdZKGlaTQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782942380; c=relaxed/simple; bh=C7x1bBUB3ipaklSunXyuzpRFreXcxCrCv/adfePHq8c=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=CU5gAp5t39G52jJqjwqteIAkdh2sE3XC/9GoKUbKhMg6YZDNFtuLFPB1FZwNZyHJ+BN+v9ytvBxO0vOQdH90Ygq8ONSXwXsS8AYKpvd379wCjGZuTVAIFLCIhVMflOzhBrHAM0osRkSmFogu71H/AUOIhS4ZgMTQbb5aidAx8BY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jstultz.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=YcAx4+pQ; arc=none smtp.client-ip=209.85.214.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jstultz.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="YcAx4+pQ" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2c8284701c2so13370275ad.1 for ; Wed, 01 Jul 2026 14:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1782942378; x=1783547178; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:from:to:cc:subject:date:message-id:reply-to; bh=lsMNequ0dxsvBsGkhR0FwIhxw7SJ9SduRAIq4EkGyNk=; b=YcAx4+pQOnq/Dw7VF3xz/n1Sb4TU7w0JZGbX6xwi+CmpzcNnDUDY30sXskVqdTRzQu ZF9lHoVtTIBjQtzxJ8sVhIRMdMtepris6/mL8OwrD0QwVAUOzuq9LWKV/yg9HNgnMmJa anAkpfMLEClP3kPa6269MwfLXdakCejGs1olpwTdW/KxwJQz+1arUQupxd0gcsPrmAZI 4RcL+ZIceyK7icx60t3znkVgr83Z57KKLv2LgRCrcX105Hzg4NtZ88NDas6w9/zjiFQ5 gpjQmcA/JNAN/POSLqCimgZkmsEsvWpJIvYMH81iJNJBw8N16EgYQ5j/nBwcLc2MBfPB Tebg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782942378; x=1783547178; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lsMNequ0dxsvBsGkhR0FwIhxw7SJ9SduRAIq4EkGyNk=; b=MNnsPnF4Fo8u+eBPN/93LEi1aMaFqcGvS7fYhzgcx3YVDPry10nO7bTmPh9M1s97ry cJ9SX4j/ifmYt9txBIVToJoNga0Os+V/jm+aM0CkZvr022OC0dU8ir8BGpw7kgD1STL1 h4PDf/ihylvtxW6rM26tUFd1onpCtxVrdzt0zDPa/mJ3084IdRRL84odEWzjuQoBPvWw nhkBIUUfQ1z6U6xwXC5IfQdIJ40g8Ev5ct4EhnwjG0jXFq5BRDq0jvz3wVgeRR6zbEEv VEyHMDKzXgiozx0XQWqDI5kcmWBOPL7MP+PyVpCroJD7JWgiDOMH2ApVNyhOTuiKMlQp Ho/w== X-Gm-Message-State: AOJu0YzhPY0kG0AIeeF+kQk+oUjxfsX0BcG5CQqaucptTxVXGvD4GKlR t7hN1WdL1+Ehwp+/U4PetoX7Aps8066KocDW0aUQl+rGmZXcOzLgWVJw/AG3cXKGQlPXJaREG0c 7eelYnBNme9HKAq9ZY3k7ng2o1fAzU7wRZtcHnuTPHFAG8SaF3T6GCPl8Xc3OUmvUCFtO03BkbQ oXcFcuStZ0y5xOszJAzvQdLqN3siM8g0obXFcEjytOkiva0nN3 X-Received: from plcu19.prod.google.com ([2002:a17:903:3093:b0:2c7:fd2d:9f2d]) (user=jstultz job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:e943:b0:2c9:bd30:e6ff with SMTP id d9443c01a7336-2ca912078b4mr22613565ad.39.1782942377912; Wed, 01 Jul 2026 14:46:17 -0700 (PDT) Date: Wed, 1 Jul 2026 21:45:55 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.55.0.rc0.799.gd6f94ed593-goog Message-ID: <20260701214615.3773339-1-jstultz@google.com> Subject: [PATCH v30 0/7] Sleeping Owner Handling for Proxy Execution (v30) From: John Stultz To: LKML Cc: John Stultz , Joel Fernandes , Qais Yousef , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , Will Deacon , Waiman Long , Boqun Feng , "Paul E. McKenney" , Metin Kaya , Xuewen Yan , K Prateek Nayak , Thomas Gleixner , Daniel Lezcano , Suleiman Souhlal , kuyo chang , hupu , Vasily Gorbik , kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey All, With some nice progress made recently, I wanted to move on to sending out the next major component of Proxy Execution: Sleeping Owner Handling. As always, I=E2=80=99m trying to submit this larger work in smallish digestible pieces. A quick overview of the journey so far: 1) prep patches 2) single rq proxying 3) simple donor migration 4) optimized donor migration 5) sleeping owner handling <- We are here! 6) chain level balancing 7) proxy rwsems 8) ... In this chunk, there is more than just sleeping owner handling: I'm including some core-scheduling fixes from Vasily Gorbik and K Prateek, as well as an optimization to do chain migration left over from the last chunk. But the substantial part of this chunk is the sleeping owner handling, which addresses what to do when a task is blocked on a mutex who=E2=80=99s owner is sleeping. Since there is nothing we can do to boost the sleeping owner at that point, we instead deactivate and queue the waiter on a list attached to the owner. Then when the owner wakes up, we will activate the waiters on the same runqueue, so they can then boost the owner to run. But since the simple sounding things hide subtlety, this ends up being a pretty complex bit of logic. You can effectively get trees of waiters, and its possible to have tasks in the middle of the tree be woken up. Then handling wakeups as they cascade down the tree properly is also a bit complex, as there are extra lists to manage the recursive style work without actually recursing. Hopefully the earlier patches will be easy to queue, but I suspect there will be lots of review feedback for me to address in the last one. :) I'd love to get further feedback on any place where these patches are confusing, or could use additional clarifications. Additionally I=E2=80=99d appreciate any testing or comments that folks have with the full Proxy Execution series! You can find the full Proxy Exec series here: https://github.com/johnstultz-work/linux-dev/commits/proxy-exec-v30-7.2-r= c1/ https://github.com/johnstultz-work/linux-dev.git proxy-exec-v30-7.2-rc1 New changes to the full patch series in this revision include: * Rebased on top of Peter=E2=80=99s cleanups and improvements which landed in 7.2-rc1 * Added an optimization to the activate_blocked_waiters logic which was causing performance impact compared to the !proxy case * Pulled in some of Andrea Righi=E2=80=99s sched_ext + proxy compatibility improvements (I=E2=80=99ve unfortunately not had much time to focus on this yet, so I=E2=80=99ve not done much testing!) Issues still to address with the full series: * Need to do more work integrating and testing Andrea=E2=80=99s sched_ext changes * Reevaluate performance regression K Prateek Nayak found with the full series. * The chain migration functionality needs further iterations and better validation to ensure it truly maintains the RT/DL load balancing invariants (despite this being broken in vanilla upstream with RT_PUSH_IPI currently) Future work: * Expand to more locking primitives: Suleiman is looking at pi-futexes, and using proxy for Binder PI is something else we=E2=80=99re exploring. * Eventually: Work to replace rt_mutexes and get things happy with PREEMPT_RT Credit/Disclaimer: =E2=80=94-------------------- As always, this Proxy Execution series has a long history with lots of developers that deserve credit: First described in a paper[1] by Watkins, Straub, Niehaus, then from patches from Peter Zijlstra, extended with lots of work by Juri Lelli, Valentin Schneider, and Connor O'Brien. (and thank you to Steven Rostedt for providing additional details here!). Thanks also to Joel Fernandes, Dietmar Eggemann, Metin Kaya, K Prateek Nayak and Suleiman Souhlal for their substantial review, suggestion, and patch contributions. So again, many thanks to those above, as all the credit for this series really is due to them - while the mistakes are surely mine. Thanks so much! -john [1] https://static.lwn.net/images/conf/rtlws11/papers/proc/p38.pdf Cc: Joel Fernandes Cc: Qais Yousef Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Juri Lelli Cc: Vincent Guittot Cc: Dietmar Eggemann Cc: Valentin Schneider Cc: Steven Rostedt Cc: Ben Segall Cc: Zimuzo Ezeozue Cc: Will Deacon Cc: Waiman Long Cc: Boqun Feng Cc: "Paul E. McKenney" Cc: Metin Kaya Cc: Xuewen Yan Cc: K Prateek Nayak Cc: Thomas Gleixner Cc: Daniel Lezcano Cc: Suleiman Souhlal Cc: kuyo chang Cc: hupu Cc: Vasily Gorbik Cc: kernel-team@android.com John Stultz (4): sched/core: Avoid migrating blocked_on tasks sched: Switch rq->next_class in proxy_reset_donor() sched: Break out core of attach_tasks() helper into sched.h sched: Migrate whole chain in proxy_migrate_task() Peter Zijlstra (1): sched: Add deactivated (sleeping) owner handling to find_proxy_task() Vasily Gorbik (2): sched/core: Don't steal a proxy-exec donor sched/core: Don't proxy-exec unmatched cookie lock owners include/linux/sched.h | 7 + init/init_task.c | 6 + kernel/fork.c | 6 + kernel/sched/core.c | 338 ++++++++++++++++++++++++++++++++++++++---- kernel/sched/fair.c | 16 +- kernel/sched/sched.h | 19 +++ 6 files changed, 349 insertions(+), 43 deletions(-) --=20 2.55.0.rc0.799.gd6f94ed593-goog