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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.