The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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 --]

  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