From: David Vernet <void@manifault.com>
To: Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH RESEND sched_ext/for-6.12] sched_ext: Don't use double locking to migrate tasks across CPUs
Date: Thu, 8 Aug 2024 13:19:27 -0500 [thread overview]
Message-ID: <20240808181927.GE6223@maniforge> (raw)
In-Reply-To: <ZrQAB_d1WSqgYQmB@slm.duckdns.org>
[-- Attachment #1: Type: text/plain, Size: 3053 bytes --]
On Wed, Aug 07, 2024 at 01:15:19PM -1000, Tejun Heo wrote:
Hi Tejun,
[...]
> -static bool move_task_to_local_dsq(struct rq *rq, struct task_struct *p,
> - u64 enq_flags)
> +static bool move_task_to_local_dsq(struct task_struct *p, u64 enq_flags,
> + struct rq *src_rq, struct rq *dst_rq)
> {
> - struct rq *task_rq;
> -
> - lockdep_assert_rq_held(rq);
> + lockdep_assert_rq_held(src_rq);
>
> /*
> - * If dequeue got to @p while we were trying to lock both rq's, it'd
> - * have cleared @p->scx.holding_cpu to -1. While other cpus may have
> - * updated it to different values afterwards, as this operation can't be
> + * If dequeue got to @p while we were trying to lock @src_rq, it'd have
> + * cleared @p->scx.holding_cpu to -1. While other cpus may have updated
> + * it to different values afterwards, as this operation can't be
> * preempted or recurse, @p->scx.holding_cpu can never become
> * raw_smp_processor_id() again before we're done. Thus, we can tell
> * whether we lost to dequeue by testing whether @p->scx.holding_cpu is
> * still raw_smp_processor_id().
> *
> + * @p->rq couldn't have changed if we're still the holding cpu.
> + *
> * See dispatch_dequeue() for the counterpart.
> */
> - if (unlikely(p->scx.holding_cpu != raw_smp_processor_id()))
> + if (unlikely(p->scx.holding_cpu != raw_smp_processor_id()) ||
> + WARN_ON_ONCE(src_rq != task_rq(p))) {
> + raw_spin_rq_unlock(src_rq);
> + raw_spin_rq_lock(dst_rq);
> return false;
> + }
>
> - /* @p->rq couldn't have changed if we're still the holding cpu */
> - task_rq = task_rq(p);
> - lockdep_assert_rq_held(task_rq);
> -
> - WARN_ON_ONCE(!cpumask_test_cpu(cpu_of(rq), p->cpus_ptr));
> - deactivate_task(task_rq, p, 0);
> - set_task_cpu(p, cpu_of(rq));
> - p->scx.sticky_cpu = cpu_of(rq);
> + /* the following marks @p MIGRATING which excludes dequeue */
> + deactivate_task(src_rq, p, 0);
> + set_task_cpu(p, cpu_of(dst_rq));
> + p->scx.sticky_cpu = cpu_of(dst_rq);
> +
> + raw_spin_rq_unlock(src_rq);
> + raw_spin_rq_lock(dst_rq);
>
> /*
> * We want to pass scx-specific enq_flags but activate_task() will
> * truncate the upper 32 bit. As we own @rq, we can pass them through
> * @rq->scx.extra_enq_flags instead.
> */
> - WARN_ON_ONCE(rq->scx.extra_enq_flags);
> - rq->scx.extra_enq_flags = enq_flags;
> - activate_task(rq, p, 0);
> - rq->scx.extra_enq_flags = 0;
> + WARN_ON_ONCE(!cpumask_test_cpu(cpu_of(dst_rq), p->cpus_ptr));
Hmmm, what's to stop someone from issuing a call to
set_cpus_allowed_ptr() after we drop the src_rq lock above? Before we
held any relevant rq lock so everything should have been protected, but
I'm not following how we prevent racing with the cpus_allowed logic in
core.c here.
> + WARN_ON_ONCE(dst_rq->scx.extra_enq_flags);
> + dst_rq->scx.extra_enq_flags = enq_flags;
> + activate_task(dst_rq, p, 0);
> + dst_rq->scx.extra_enq_flags = 0;
>
> return true;
> }
Thanks,
David
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-08-08 18:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-07 23:14 [sched_ext/for-6.12] sched_ext: Don't use double locking to migrate tasks across CPUs Tejun Heo
2024-08-07 23:15 ` [PATCH RESEND sched_ext/for-6.12] " Tejun Heo
2024-08-08 18:19 ` David Vernet [this message]
2024-08-08 18:24 ` Tejun Heo
2024-08-08 18:25 ` David Vernet
2024-08-13 19:09 ` Tejun Heo
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=20240808181927.GE6223@maniforge \
--to=void@manifault.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--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