From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) (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 33BA5327C00 for ; Fri, 24 Jul 2026 18:12:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.197 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784916764; cv=none; b=eM1lFR76jvrbb+dZzThVQvPK3oxBbeeIsTlz9kP/oofyvt83f5Nyqk9rGmHGf3tElOrl0iYsohnzc6NGec3NgG1DzjNyj2yOM+DokekRo6q9pXAb4gQYUJ39rluktVW4ZgNqtv6v8lpGQ7A+uW26U62ZvWtPDV599x73YLlAQkA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784916764; c=relaxed/simple; bh=HIsDxCSesP9PEqn3CrOSEmcUsvurOXdvw7H3w6olGwI=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=KH/f2r7uVodL9lP5nKhq1LiElCVuucSIlq0x2p8b5t5x7V6ZCU7sdhwAQBlZ2JJDZATjg4VEq+fcLUKxA+qfggJ/LqoVrzQV/1RwqSooa65bOYxdbphvoff6x44adyzptlGrHRu1pxr2rZgtntQHmu60Ep/Lp3xjx09Gwb7t+WE= 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=Jl6x76Wg; arc=none smtp.client-ip=209.85.210.197 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="Jl6x76Wg" Received: by mail-pf1-f197.google.com with SMTP id d2e1a72fcca58-848474825ffso906552b3a.0 for ; Fri, 24 Jul 2026 11:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1784916762; x=1785521562; 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=v0j1dN1SHuDNHqVHUR3Ik4XDxqv6ZLvvMpfAzk/YSu4=; b=Jl6x76WgKvqrmGnpYuqcyslPE4WMJv/JzudsBFq91Vf5B69kqTWf3uEeeOqpHLTCDt ziL7oo80toK0U2DlL31YOaNUO2i8eciwgp7Gfgp1sNhlnq6Od0IVCszh2C2l6YPSSY8W mVwa//hPXjECO35b3bEOFgJQP0l9ApKBfORPMEk/ycPdmzWEogKTZ4H7+bExLgnizRC/ bVJg1TTBw9eiv4RMtD/WlegffshnbwLn3BO3ehLBGhXr4LcT7pLt0mEdaz4xbdjw04et jtb02tx3HVXqsFnTT2cEGuk3ktK6TBGZRFH2yNgeM/2BrnJw3sMTS/3wKvPEPWYdskji p/eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784916762; x=1785521562; 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=v0j1dN1SHuDNHqVHUR3Ik4XDxqv6ZLvvMpfAzk/YSu4=; b=bjp2aUo7JDLa5kuIJxbBGfzmymd+zUWvC0Qw+hQ16PTB5woa2Ne4kkRZjtK7kAFEEQ MISkJsiPBsXYJ6bXuw8v9kkFhHt1G8l+0wL50NN/KF+naYgS88gV3KHK4/8O5pxxwW3u DkwEEI9uB/GFxyg0+Yblsm185SQ/5ZPDJQB/txrycJNIV7XsR0SJ1bTfy6jTwgOEXCIJ J5TC2HyBKlKcBPvhvWeiYGLYT5aSXORA/vRdHnLHkzm3Q1E9oN4l5Hhsjbavuk4ixQ2C j+tWD8/0Klt14KYyCN/kCMWHqNZTFq8MKz8ChKxh+aq2absTKkYKkKnlV8rQyKoobe3l /uIA== X-Gm-Message-State: AOJu0Ywrz7yG/FrDahnV9EtX16UMYsYFqxY8uMskwK7X2d5FRyCe7zYX Z02mMkeSrCUVeDix/XWtDWHiCO7eo9O5LgREi6V3PS4GUGv/jID4CZBi59SLdiEGg4kk32S9QCT fjgoJqDoQoAM0iCix+0GJ+S8yJ+Iabindjl2dQrGXJfU/0A/woHgXJA0kGFBz87QyufnZ1Oxk33 GaMavD4XPk4lw4WvjcwW5RGeXCfEcRkvzwm0FNDwAz9firMdB/ X-Received: from pgbfm24.prod.google.com ([2002:a05:6a02:4998:b0:c99:aff5:707b]) (user=jstultz job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2e26:b0:848:52bf:4296 with SMTP id d2e1a72fcca58-84e4e273fd7mr1323730b3a.15.1784916762025; Fri, 24 Jul 2026 11:12:42 -0700 (PDT) Date: Fri, 24 Jul 2026 18:12:14 +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.229.g6434b31f56-goog Message-ID: <20260724181238.3445275-1-jstultz@google.com> Subject: [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, I wanted to send out another 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 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.229.g6434b31f56-goog