From: David Vernet <void@manifault.com>
To: Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
schatzberg.dan@gmail.com, mingo@redhat.com, peterz@infradead.org,
changwoo@igalia.com, righi.andrea@gmail.com
Subject: Re: [PATCH 3/6] sched_ext: Make @rf optional for dispatch_to_local_dsq()
Date: Wed, 10 Jul 2024 11:10:25 -0500 [thread overview]
Message-ID: <20240710161025.GA317151@maniforge> (raw)
In-Reply-To: <20240709212137.1199269-4-tj@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4167 bytes --]
On Tue, Jul 09, 2024 at 11:21:09AM -1000, Tejun Heo wrote:
> dispatch_to_local_dsq() may unlock the current rq when dispatching to a
> local DSQ on a different CPU. This function is currently called from the
> balance path where the rq lock is pinned and the associated rq_flags is
> available to unpin it.
>
> dispatch_to_local_dsq() will be used to implement direct dispatch to a local
> DSQ on a remote CPU from the enqueue path where it will be called with rq
> locked but not pinned. Make @rf optional so that the function can be used
> from a context which doesn't pin the rq lock.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: David Vernet <void@manifault.com>
> ---
> kernel/sched/ext.c | 21 +++++++++++++--------
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
> index 52340ac8038f..e96727460df2 100644
> --- a/kernel/sched/ext.c
> +++ b/kernel/sched/ext.c
> @@ -2040,7 +2040,7 @@ static bool move_task_to_local_dsq(struct rq *rq, struct task_struct *p,
> /**
> * dispatch_to_local_dsq_lock - Ensure source and destination rq's are locked
> * @rq: current rq which is locked
> - * @rf: rq_flags to use when unlocking @rq
> + * @rf: optional rq_flags to use when unlocking @rq if its lock is pinned
> * @src_rq: rq to move task from
> * @dst_rq: rq to move task to
> *
> @@ -2052,17 +2052,20 @@ static bool move_task_to_local_dsq(struct rq *rq, struct task_struct *p,
> static void dispatch_to_local_dsq_lock(struct rq *rq, struct rq_flags *rf,
> struct rq *src_rq, struct rq *dst_rq)
> {
> - rq_unpin_lock(rq, rf);
> + if (rf)
> + rq_unpin_lock(rq, rf);
>
> if (src_rq == dst_rq) {
> raw_spin_rq_unlock(rq);
> raw_spin_rq_lock(dst_rq);
> } else if (rq == src_rq) {
> double_lock_balance(rq, dst_rq);
> - rq_repin_lock(rq, rf);
> + if (rf)
> + rq_repin_lock(rq, rf);
> } else if (rq == dst_rq) {
> double_lock_balance(rq, src_rq);
> - rq_repin_lock(rq, rf);
> + if (rf)
> + rq_repin_lock(rq, rf);
It feels kind of weird to have the callee need to know about pinning
requirements in the caller instead of vice versa. I mean, I guess it's inherent
to doing an unpin / repin inside of a locked region, but it'd be nice if we
could minimize the amount of variance in that codepath regardless. I think what
you have is correct, but maybe it'd simpler if we just pinned in the caller on
the enqueue path? That way the semantics of when locks can be dropped is
consistent in dispatch_to_local_dsq().
> } else {
> raw_spin_rq_unlock(rq);
> double_rq_lock(src_rq, dst_rq);
> @@ -2072,7 +2075,7 @@ static void dispatch_to_local_dsq_lock(struct rq *rq, struct rq_flags *rf,
> /**
> * dispatch_to_local_dsq_unlock - Undo dispatch_to_local_dsq_lock()
> * @rq: current rq which is locked
> - * @rf: rq_flags to use when unlocking @rq
> + * @rf: optional rq_flags to use when unlocking @rq if its lock is pinned
> * @src_rq: rq to move task from
> * @dst_rq: rq to move task to
> *
> @@ -2084,7 +2087,8 @@ static void dispatch_to_local_dsq_unlock(struct rq *rq, struct rq_flags *rf,
> if (src_rq == dst_rq) {
> raw_spin_rq_unlock(dst_rq);
> raw_spin_rq_lock(rq);
> - rq_repin_lock(rq, rf);
> + if (rf)
> + rq_repin_lock(rq, rf);
> } else if (rq == src_rq) {
> double_unlock_balance(rq, dst_rq);
> } else if (rq == dst_rq) {
> @@ -2092,7 +2096,8 @@ static void dispatch_to_local_dsq_unlock(struct rq *rq, struct rq_flags *rf,
> } else {
> double_rq_unlock(src_rq, dst_rq);
> raw_spin_rq_lock(rq);
> - rq_repin_lock(rq, rf);
> + if (rf)
> + rq_repin_lock(rq, rf);
> }
> }
> #endif /* CONFIG_SMP */
> @@ -2214,7 +2219,7 @@ enum dispatch_to_local_dsq_ret {
> /**
> * dispatch_to_local_dsq - Dispatch a task to a local dsq
> * @rq: current rq which is locked
> - * @rf: rq_flags to use when unlocking @rq
> + * @rf: optional rq_flags to use when unlocking @rq if its lock is pinned
> * @dsq_id: destination dsq ID
> * @p: task to dispatch
> * @enq_flags: %SCX_ENQ_*
> --
> 2.45.2
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-07-10 16:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-09 21:21 [PATCHSET sched_ext/for-6.11] sched_ext: Allow SCX_DSQ_LOCAL_ON for direct dispatches Tejun Heo
2024-07-09 21:21 ` [PATCH 1/6] sched: Move struct balance_callback definition upward Tejun Heo
2024-07-10 18:53 ` David Vernet
2024-07-09 21:21 ` [PATCH 2/6] sched_ext: Open-code task_linked_on_dsq() Tejun Heo
2024-07-10 8:56 ` Andrea Righi
2024-07-10 18:53 ` David Vernet
2024-07-09 21:21 ` [PATCH 3/6] sched_ext: Make @rf optional for dispatch_to_local_dsq() Tejun Heo
2024-07-10 8:59 ` Andrea Righi
2024-07-10 11:41 ` Peter Zijlstra
2024-07-10 16:39 ` Tejun Heo
2024-07-10 16:10 ` David Vernet [this message]
2024-07-10 16:46 ` Tejun Heo
2024-07-09 21:21 ` [PATCH 4/6] sched_ext: s/SCX_RQ_BALANCING/SCX_RQ_IN_BALANCE/ and add SCX_RQ_IN_WAKEUP Tejun Heo
2024-07-10 18:54 ` David Vernet
2024-07-09 21:21 ` [PATCH 5/6] sched_ext: Allow SCX_DSQ_LOCAL_ON for direct dispatches Tejun Heo
2024-07-10 18:51 ` David Vernet
2024-07-10 23:43 ` Tejun Heo
2024-07-09 21:21 ` [PATCH 6/6] sched_ext/scx_qmap: Pick idle CPU for direct dispatch on !wakeup enqueues Tejun Heo
2024-07-10 19:25 ` David Vernet
2024-07-11 0:05 ` Tejun Heo
2024-07-10 9:01 ` [PATCHSET sched_ext/for-6.11] sched_ext: Allow SCX_DSQ_LOCAL_ON for direct dispatches Andrea Righi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240710161025.GA317151@maniforge \
--to=void@manifault.com \
--cc=changwoo@igalia.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=righi.andrea@gmail.com \
--cc=schatzberg.dan@gmail.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox