mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: K Prateek Nayak <kprateek.nayak@amd.com>
To: <luoliang@kylinos.cn>, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>
Cc: Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, "Mel Gorman" <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched/deadline: Use task_on_rq_migrating() helper
Date: Mon, 8 Jun 2026 12:40:21 +0530	[thread overview]
Message-ID: <588d2bf2-824b-4c06-82b6-15892d1263da@amd.com> (raw)
In-Reply-To: <20260608065307.280995-1-luoliang@kylinos.cn>

Hello Liang,

On 6/8/2026 12:23 PM, luoliang@kylinos.cn wrote:
> From: Liang Luo <luoliang@kylinos.cn>
> 
> Replace the open-coded "p->on_rq == TASK_ON_RQ_MIGRATING" comparisons
> in enqueue_task_dl() and dequeue_task_dl() with the existing
> task_on_rq_migrating() helper, consistent with the rest of the
> scheduler code.

Good cleanup but ...

> 
> The helper uses READ_ONCE() when loading ->on_rq, which was added by
> commit c546951d9c93 ("sched/core: Use READ_ONCE()/WRITE_ONCE() in
> move_queued_task()/task_rq_lock()") for LKMM compliance.  As documented
> in that commit, move_queued_task() synchronizes with task_rq_lock():
> 
>   move_queued_task()                task_rq_lock()
>   [S] ->on_rq = MIGRATING          [L] rq = task_rq()
>   WMB (__set_task_cpu())           ACQUIRE (rq->lock)
>   [S] ->cpu = new_cpu              [L] ->on_rq
> 
> The READ_ONCE() on the ->on_rq load ensures proper pairing with the
> WRITE_ONCE() on the writer side.  The open-coded checks in deadline.c
> lack this annotation.

... this extra context feels unnecessary since the p->on_rq indicator
is always stable at the time of dequeue / enqueue.

The calling context already holds the rq_lock() (and sometimes, also
the p->pi_lock) so there are no concurrent writers for it to pair with
- in fact this same context will set p->on_rq back to TASK_ON_RQ_QUEUED
after it is done enqueuing and before dropping the rq_lock().

> 
> No functional change.
> 
> Signed-off-by: Liang Luo <luoliang@kylinos.cn>

For the change itself, feel free to include:

Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>

> ---
>  kernel/sched/deadline.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 7db4c87df83b..9d2c42b8661f 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -2335,7 +2335,7 @@ static void enqueue_task_dl(struct rq *rq, struct task_struct *p, int flags)
>         check_schedstat_required();
>         update_stats_wait_start_dl(dl_rq_of_se(&p->dl), &p->dl);
> 
> -       if (p->on_rq == TASK_ON_RQ_MIGRATING)
> +       if (task_on_rq_migrating(p))
>                 flags |= ENQUEUE_MIGRATING;
> 
>         enqueue_dl_entity(&p->dl, flags);
> @@ -2354,7 +2354,7 @@ static bool dequeue_task_dl(struct rq *rq, struct task_struct *p, int flags)
>  {
>         update_curr_dl(rq);
> 
> -       if (p->on_rq == TASK_ON_RQ_MIGRATING)
> +       if (task_on_rq_migrating(p))
>                 flags |= DEQUEUE_MIGRATING;
> 
>         dequeue_dl_entity(&p->dl, flags);
> --
> 2.25.1
> 

-- 
Thanks and Regards,
Prateek


  reply	other threads:[~2026-06-08  7:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-08  6:53 luoliang
2026-06-08  7:10 ` K Prateek Nayak [this message]
2026-06-08  7:55 ` [PATCH v2] " luoliang
2026-06-09  8:32   ` [tip: sched/core] " tip-bot2 for Liang Luo
2026-06-08  8:01 ` [PATCH] " Peter Zijlstra
2026-06-09  5:52   ` luoliang

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=588d2bf2-824b-4c06-82b6-15892d1263da@amd.com \
    --to=kprateek.nayak@amd.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luoliang@kylinos.cn \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /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

all inboxes | Powered by JetHome®