From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) (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 43BD6223DFF for ; Thu, 20 Nov 2025 01:54:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.217.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763603656; cv=none; b=Cq1/fwRnttP6SLYrNi3GEQmVm/eBSQc32b4m9/HIIY0Vfa0o86rw3ma4eD6+m9GNIKHUWWFHTx5k32xObkWqrOXz3Z7zwf25sm6QrmQD7c8gL/OcnI5Z9IDLhvlPx348j3VubIhNIYkr4p9iCyzKXCwkMQg3o2o3sW9/GLNuGDA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763603656; c=relaxed/simple; bh=u7geJ/sUN8Tp7NjHwmTSukrYv0RBR3cRVRT3NV3aiw4=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=BuWbVIxMXfvi9waaI2GdDRzpNYZBE/KOpOalaX1ewoZ/1HHQWr64I/S4ydotYJojFHvAGy0EywhoSXT3yGrD9tB65i9wyOHdkGtZbXyfUrCS84qMLZ99nLri4cU2IkFM/oLzcRGhephPz0HX5mauJa4v1lynkqrGX6ofKT4TB0Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=eC6mN0Ap; arc=none smtp.client-ip=209.85.217.44 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=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="eC6mN0Ap" Received: by mail-vs1-f44.google.com with SMTP id ada2fe7eead31-5dd88eef2f3so158561137.3 for ; Wed, 19 Nov 2025 17:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1763603652; x=1764208452; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=nP/ST1RIAbWlgAAbQAkbPtH8c4PBSxMKB8l63xKOl64=; b=eC6mN0ApnCANt3poaHTx4JMrm+tLDcikclwwvbRAIe9rIVv9zOOiPApW1UrpaIvSui dhJ0pD8WIGLeRs4KSzG8DxjbxIMPx1SPgEo0YKD97ZRIRYpTFIjoHq+bUo96dibM4Hpy mb8TWBafTC+561Tky1AMB4A0E0XjO/A5qqoIq93lNnq8w0XhdU+xUmattbc/pvDM3NS5 MtSEa+yfwvc5RaANiE3a9QwFjln/laTrnxu0ERV6KsSZORJzj/j5TPhr4ApIKn+hvp2+ YMwTPVQAL5WY4/6Z0OIE8IB8dovSi9zUh6MmvI2AymVU7Ize7xTgPchT0cTaM6TDMr0X mwIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763603652; x=1764208452; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=nP/ST1RIAbWlgAAbQAkbPtH8c4PBSxMKB8l63xKOl64=; b=rDDijDfl+VLDYpeK+NuzCY2XvaET0yK0k2z13kO7FY8NH+0yWr6Bu9QSV5eauLVrjU hzBWVlKfwXLbMs7RBshvI/y2Ngh+vPvdpQ8gk6qRw6PIk3uZ8TGhkkCYVX2I/EbtW6jp o3e9/8+2D7VTH44AEt9knmo02kvULlCbNzj887B9ijO4Yz//nVmsPvQGAvwgZAImd/mm yPHh5UZPT7sfTI7yeC/hJV3Qhi9KXB6LMlE0Zni6FQfsgcxhapLSe8M6k4XPIdAvbKsf PgbfCST+lN3YfmTiq6Fa995/j/o2DlOLIOeV6X3VQWdRkaISOhXCl4EzVVjEN9ZwQ0r/ bKwg== X-Gm-Message-State: AOJu0YxtVvNQsUO/tjj5aSGeEPrCdUdyTUWZD7tUmdMsrDDwwSKOzXX5 fypR6MZpN9WAG0W4s3mhPWrgAAnUBeYukiYi4k4OrZTKrA1wKm0BltrYp6QHXJnmVEFYfpTL2vB HYm6nC4pdP0vT+KwsDKjPV0Uujf1K82Yc+JrvUIM= X-Gm-Gg: ASbGncsMxZ48k2cvX9j8WMsbzmep8prUxWMzzwBJgr1FvyLI4T0/xayd9x57Os7KA9B 1OdTrADx/gLH3pNmtV9E0DFXtaoavofmUZj9od1fEWt3EQL+HYHY5xarSDzkwqdfUtPyavV95sw QpEoa+DuZ+J9P+UvZTMzCZD8F8Nsa8N2IhFqVZF5jS5Q5WKSCfN7OwMiRgOV32V6DqJEFbAAlG5 zwkli+cZsVF9ljoBcrAHQ4peHgX8nqOGXDCYfbj/63qeKHNeqbY64NAXmIoc3NhnOqLRodxlhmk CsUzd/GEtRmfwEAsxy5RkCUIGQ== X-Google-Smtp-Source: AGHT+IHUTlAukRfD9gMnK8Iv7GMwzXYHo2o/afeKJgR3wqVnTM0EiPTWCG/gkBesIflv+skU7I0rQnM94AqEc6rbd5M= X-Received: by 2002:a05:6102:4a8b:b0:5dd:7a30:ec0d with SMTP id ada2fe7eead31-5e1bbbd96c4mr721817137.2.1763603651784; Wed, 19 Nov 2025 17:54:11 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20251030001857.681432-1-jstultz@google.com> <20251030001857.681432-7-jstultz@google.com> <0c337bca-4ecf-4654-9256-df766573c7de@amd.com> In-Reply-To: From: John Stultz Date: Wed, 19 Nov 2025 17:53:58 -0800 X-Gm-Features: AWmQ_bli1_2jWUsdH0vIRpVebg6BBhzmW1Kp1aORx9qKZX_VG3MiYqspGQYt2KU Message-ID: Subject: Re: [PATCH v23 6/9] sched: Handle blocked-waiter migration (and return migration) To: K Prateek Nayak Cc: LKML , Joel Fernandes , Qais Yousef , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , Mel Gorman , Will Deacon , Waiman Long , Boqun Feng , "Paul E. McKenney" , Metin Kaya , Xuewen Yan , 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 On Sun, Nov 9, 2025 at 8:48=E2=80=AFPM K Prateek Nayak wrote: > > Hello John, > > On 11/8/2025 4:48 AM, John Stultz wrote: > >>> @@ -6689,26 +6834,41 @@ find_proxy_task(struct rq *rq, struct task_st= ruct *donor, struct rq_flags *rf) > >>> return NULL; > >>> } > >>> > >>> + if (task_current(rq, p)) > >>> + curr_in_chain =3D true; > >>> + > >>> owner =3D __mutex_owner(mutex); > >>> if (!owner) { > >>> /* > >>> - * If there is no owner, clear blocked_on > >>> - * and return p so it can run and try to > >>> - * acquire the lock > >>> + * If there is no owner, either clear blocked_o= n > >>> + * and return p (if it is current and safe to > >>> + * just run on this rq), or return-migrate the = task. > >>> */ > >>> - __clear_task_blocked_on(p, mutex); > >>> - return p; > >>> + if (task_current(rq, p)) { > >>> + __clear_task_blocked_on(p, NULL); > >>> + return p; > >>> + } > >>> + action =3D NEEDS_RETURN; > >>> + break; > >>> } > >>> > >>> if (!READ_ONCE(owner->on_rq) || owner->se.sched_delayed= ) { > >> > >> Should we handle task_on_rq_migrating() in the similar way? > >> Wait for the owner to finish migrating and look at the > >> task_cpu(owner) once it is reliable? > > > > Hrm. I'm not quite sure I understand your suggestion here. Could you > > expand a bit here? Are you thinking we should deactivate the donor > > when the owner is migrating? What would then return the donor to the > > runqueue? Just rescheduling idle so that we drop the rq lock > > momentarily should be sufficient to make sure the owner can finish > > migration. > > In find_proxy_task() we have: > > if (!READ_ONCE(owner->on_rq) || owner->se.sched_delayed) { > /* Returns rq->idle or NULL */ > } > > /* > * Owner can be task_on_rq_migrating() at this point > * since it is in turn blocked on a lock owner on a > * different CPU. > */ > > owner_cpu =3D task_cpu(owner); /* Prev CPU */ > if (owner_cpu !=3D this_cpu) { > ... > action =3D MIGRATE; > break; > } > > > So in the end we can migrate to the previous CPU of the owner > and the previous CPU has to do a chain migration again. I'm > probably overthinking about a very unlikely scenario here :) Ok, so you're suggesting maybe putting the if (task_on_rq_migrating(owner)) case ahead of the if (owner_cpu !=3D this_cpu) check? Let me give that a whirl and see how it does. thanks -john