From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) (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 7BC58EEB3 for ; Fri, 7 Aug 2026 03:52:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.200 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786074757; cv=none; b=sEMAbbJ6NWWT5//I88Z225e2+juoCWUue4Ap6o1qHumDt5ARsNKQEN6V9vL7MvbPNanxKm0e/UaApHBKAiR9lLVoV6NU8mTNjpsOUGTZiYg38AIFm6sc/f576yz0uyYlqYRY3t8JNIa2D1MHMroAkdFkp5b2p9TXNHL2Xjq5ODk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786074757; c=relaxed/simple; bh=v4xAtUNrWzg090RsH9pe+BdmkVRkTu9e+6RjYDFF4JU=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=NSUJDZxwFVVXxOdNKNWwX76Z2oRqRu9cT6k43YyxHdUg4d4dI1y8RBgMN2/uym62Na1j3MlLzxXC05HrB/FJv9HifKqTs3FTKTK8qYWcbM5JfCdAQ78P4bD2mYe5QcUWUf5KrA3OYEiAYf/zbHfMOCNOsnvzPNbcMJIPoqmOUBk= 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=cgdRTM9E; arc=none smtp.client-ip=209.85.214.200 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="cgdRTM9E" Received: by mail-pl1-f200.google.com with SMTP id d9443c01a7336-2cd01a14e81so40853425ad.1 for ; Thu, 06 Aug 2026 20:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786074755; x=1786679555; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:mime-version:date:from:to:cc:subject:date:message-id :reply-to:content-type; bh=mDT1Bb/E3Ha1xJBycMXJY9S1vwEf/b86Mpat/jBOlNM=; b=cgdRTM9EwYsrhj2pmlHaLHSXmpt/uImF7pR2kOH2uLG+1k9iSAMzSrDzWZv3Mv08wR 9wVLmog2H02YKFeMb+Z4lYjRWTVFNJ86cyHg/yEwBS0WJlHv2/MTJAXq+gCWAyJ8x0g6 Htf6fZyf16qw3DMc+4GJtUxcg/SII5ZqWFlIuuA7GlZqiwjk+UemBmiRg/0pC643W4NO PAw1eNpF5EbA7SIXPcvS0fKeGeR51sJOEhdeKJWKn2ORa6zdWAFm/3s++ZE5HjujpPZ4 0AchPZcHpDdfXdkyAUqaIyCYAF/C6sbsP24dTmnQLIjISFvY2GCd+M8xeqcWxXjVHU7R mywQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786074755; x=1786679555; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:mime-version:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=mDT1Bb/E3Ha1xJBycMXJY9S1vwEf/b86Mpat/jBOlNM=; b=HvsLMWKMmiNxO6m9E6RXMJcn9ndTPUuTAmw/jSLyXp5l0/nGU68xfMQ9OB3irL0KVy QgUwTg2PJTPO6NUAoSAHHt/QfjdP2ZHtkbNsuq5hDnmSFVfBmyx7eim0A7hBUx6I9Wl4 IrR9HPoBf1NoXe5rvDEPChxl8kPWZUNCtVONGqYhVvVVBlpAQa/28a1DFtAuLv7OL6XH wfO5/z5ssoce4wBUE8SQ72C3v5MFDkUdFqzsjSmf14JBc3yQfJ7CSvg9kPCGCM4NFh6J 7rFkAJRr4O+nMOTes/3q2vSvcdB9QtN6/yTDEzbqlX1W3GybeoPKYPzXWA9/H1KKkldA aJxQ== X-Gm-Message-State: AOJu0YyEbxSK2vNa5pjzx8isWn3gbicM0pMOCGxW18aznE+1/lViubZr oMeIT0/BZKn4+5v7OrJjXZlGGt7ZgJJ1eInPptSkxaTpUs0jUts9FGVLaMwpt7Vh5zuRzNdgz5z dAP0hdXD9dqJdFyFOAuO10RU2OtXzRbFF86EDtyXy0TKeX7cKjngMLAyYSgNpNgcqrdXNWfpZI9 bHOX07w7wFGSbFr/wkKm/YW375XqjLmNPWuyaFagM7kgzrc5jw X-Received: from pljc6.prod.google.com ([2002:a17:903:3b86:b0:2cc:fd6c:c5d3]) (user=jstultz job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:fa5:b0:2c9:d8c6:1dc3 with SMTP id d9443c01a7336-2d0ca1611famr237033355ad.0.1786074754401; Thu, 06 Aug 2026 20:52:34 -0700 (PDT) Date: Fri, 7 Aug 2026 03:52:06 +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.654.g21b8a5bc05-goog Message-ID: <20260807035232.1881495-1-jstultz@google.com> Subject: [RESEND][PATCH v31 0/9] Sleeping Owner Handling for Proxy Execution (v31) 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 , kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey All, Didn=E2=80=99t get much feedback last round, as a number of folks were on vacation, so I wanted to re-send out the v31 iteration of 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 actually is more than just sleeping owner handling: I=E2=80=99m including some core-scheduling fixes from Vasily Gorbik and K Prateek, a DL fix from Christian, as well as an optimization to 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 whose 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 it's 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 two. :) I=E2=80=99d love to get further feedback on any place where these patches are confusing, or could use additional clarifications. New in v31 of this set: * Included Christian's patch to return early from yield_task_dl() when we are proxying * K Prateek's noticed a potential race where if a sleeping owner is woken in parallel with the waiter enqueuing itself on the sleeping owner, the waiting task could get stuck on that owner until it sleeps and is woken up again. So a fix for this has been made. * Maria Yu and Tengfei Fan reported an issue with rq->nr_iowait values getting out of balance, and provided a helpful reproducer. I=E2=80=99ve adjusted the logic in do_activate_blocked_waiter() to correct the imbalance. * Included changes from Andrea Righi to adapt the sleeping owner handling with his recent series to make sched_ext and proxy-exec work together (his series and my series are fully independent - I only have a two-line patch from Andrea that will be needed if both changes land in parallel). 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-v31-7.2-r= c4 https://github.com/johnstultz-work/linux-dev.git proxy-exec-v31-7.2-rc4 In the full series, there's been quite a lot of exciting changes, particularly three really interesting chunks of work from Andrea, K Prateek and Suleiman! New changes to the full patch series in this revision include: * Included Andrea=E2=80=99s sched_ext changes to support sched_ext with proxy-exec (along with a lot of pending sched_ext changes his work is built on top of)! * Included K Prateek=E2=80=99s deeper fixes to core-scheduling issues with proxy-exec! * Included first pass of Suleiman Souhlal=E2=80=99s efforts to get proxy-enabled futexes working! * Fixed a very subtle reported proxy-rwsems race with rwsem_mark_wake(), which could cause the task::blocked_on state checks to trip warnings, even when proxy-exec was disabled. * Updated test-ww_mutex patches from H=C3=A5kon Bugge * Also, I've added a small build fix at the end of the larger series branch that H=C3=A5kon Bugge reported since v31 was first sent out. Issues still to address with the full series: * After the nr_wait imbalance was addressed, Maria Yu raised a subtle difference in how the nr_iowait counting might be attributed with proxy-exec: potentially proxy-migrated donors that become blocked on sleeping owners could increment/decrement the value on the owners cpu rq, instead of on the donor=E2=80=99s original cpu rq. It=E2=80=99s unclear to me what t= he impact of this would be, if at all, but it is potentially an observable difference with proxy-exec, so I=E2=80=99m going to take a swing at addressing it. * Take a stab at lock-owner-count optimization idea from K Prateek * Reevaluate performance regression K Prateek Nayak found with the full series earlier. * 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's draft work on pi-futexes is ongoing, 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:=20 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, Suleiman Souhlal, Christian Loehle, and Andrea Righi 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: kernel-team@android.com Andrea Righi (1): sched: Distinguish proxy activations from wakeups Christian Loehle (1): sched/deadline: Ignore proxy-exec sched_yield() 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 | 350 ++++++++++++++++++++++++++++++++++++---- kernel/sched/deadline.c | 3 + kernel/sched/ext/ext.c | 8 + kernel/sched/fair.c | 16 +- kernel/sched/sched.h | 21 +++ 8 files changed, 374 insertions(+), 43 deletions(-) --=20 2.55.0.654.g21b8a5bc05-goog