All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
	mingo@redhat.com, juri.lelli@redhat.com,
	dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
	linux-kernel@vger.kernel.org, pierre.gondois@arm.com,
	qyousef@layalina.io, hongyan.xia2@arm.com,
	christian.loehle@arm.com, luis.machado@arm.com
Subject: Re: [PATCH 4/6 v8] sched/fair: Add push task mechanism for fair
Date: Fri, 5 Dec 2025 13:56:06 +0100	[thread overview]
Message-ID: <20251205125606.GA2528459@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <c5fe1adf-de43-41b0-bebc-9f47bb3c80c8@amd.com>

On Fri, Dec 05, 2025 at 06:19:07PM +0530, K Prateek Nayak wrote:
> On 12/5/2025 2:29 PM, Peter Zijlstra wrote:
> >>> Why not use move_queued_task() ?
> >>
> >> double_lock_balance() can fail and prevent being blocked waiting for
> >> new rq whereas move_queued_task() will wait, won't it ?
> >>
> >> Do you think move_queued_task() would be better ?
> > 
> > No, double_lock_balance() never fails, the return value indicates if the
> > currently held rq-lock, (the first argument) was unlocked while
> > attaining both -- this is required when the first rq is a higher address
> > than the second.
> > 
> > double_lock_balance() also puts the wait-time and hold time of the
> > second inside the hold time of the first, which gets you a quadric term
> > in the rq hold times IIRC. Something that's best avoided.
> > 
> > move_queued_task() OTOH takes the task off the runqueue you already hold
> > locked, drops this lock, acquires the second, puts the task there, and
> > returns with the dst rq locked.
> 
> So I was experimenting with:
> 
>     deactivate_task(rq, p, 0);
>     set_task_cpu(p, target_cpu);
>     __ttwu_queue_wakelist(p, target_cpu, 0);
> 
> and nothing has screamed at me yet during the benchmark runs.
> Would this be any good instead of the whole lock juggling?

This will get schedstats and any class with ->task_woken confused I
think. The IPI handler (sched_ttwu_pending / ttwu_do_activate) is
currently only geared towards doing the remote bit of ttwu.

This is fixable of course.

> Since this CPU is found to be going overloaded, pushing via an
> IPI vs taking the overhead ourselves seems to make more sense
> to me from EAS standpoint.

The performance characteristics here are very platform dependent.
Sometimes raising an IPI can be very expensive in and of itself.

> Given TTWU_QUEUE is disabled for PREEMPT_RT, I'm assuming this
> might be problematic too?

Yes, you have to check TTWU_QUEUE and have a fallback.

  reply	other threads:[~2025-12-05 12:56 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-02 18:12 [PATCH 0/6 v8] sched/fair: Add push task mechanism and handle more EAS cases Vincent Guittot
2025-12-02 18:12 ` [PATCH 1/6 v8] sched/fair: Filter false overloaded_group case for EAS Vincent Guittot
2025-12-02 18:12 ` [PATCH 2/6 v8] sched/fair: Update overutilized detection Vincent Guittot
2026-02-06 17:42   ` Qais Yousef
2025-12-02 18:12 ` [PATCH 3/6 v8] sched/fair: Prepare select_task_rq_fair() to be called for new cases Vincent Guittot
2025-12-07 13:23   ` Shrikanth Hegde
2026-02-09 13:21     ` Vincent Guittot
2026-02-06 18:03   ` Qais Yousef
2026-02-09 13:21     ` Vincent Guittot
2025-12-02 18:12 ` [PATCH 4/6 v8] sched/fair: Add push task mechanism for fair Vincent Guittot
2025-12-04 10:46   ` Peter Zijlstra
2025-12-04 14:32     ` Vincent Guittot
2025-12-04 11:29   ` Peter Zijlstra
2025-12-04 14:34     ` Vincent Guittot
2025-12-05  8:59       ` Peter Zijlstra
2025-12-05 12:49         ` K Prateek Nayak
2025-12-05 12:56           ` Peter Zijlstra [this message]
2025-12-05 13:05             ` K Prateek Nayak
2025-12-05 13:36           ` Vincent Guittot
2025-12-06  3:08             ` K Prateek Nayak
2025-12-05 13:26         ` Vincent Guittot
2025-12-07 12:13   ` Shrikanth Hegde
2026-02-09 13:17     ` Vincent Guittot
2025-12-10 14:01   ` Dietmar Eggemann
2026-02-09 13:17     ` Vincent Guittot
2026-02-06 18:21   ` Qais Yousef
2026-02-09 13:18     ` Vincent Guittot
2025-12-02 18:12 ` [RFC PATCH 5/6 v8] sched/fair: Enable idle core tracking for !SMT Vincent Guittot
2025-12-05 15:52   ` Christian Loehle
2025-12-06  2:11     ` Chen, Yu C
2025-12-06 10:18       ` Vincent Guittot
2025-12-06 10:09     ` Vincent Guittot
2025-12-08 18:43   ` Christian Loehle
2025-12-02 18:12 ` [RFC PATCH 6/6 v8] sched/fair: Add EAS and idle cpu push trigger Vincent Guittot
2026-02-06 18:30   ` Qais Yousef
2026-02-09 13:20     ` Vincent Guittot
2026-02-11  0:59       ` Qais Yousef
2025-12-03 14:06 ` [PATCH 0/6 v8] sched/fair: Add push task mechanism and handle more EAS cases Christian Loehle
2025-12-10 13:30 ` Dietmar Eggemann
2026-02-06 18:32 ` Qais Yousef
2026-02-09 13:20   ` Vincent Guittot
2026-02-26 17:34 ` Pierre Gondois
2026-03-10  4:16   ` Qais Yousef
2026-03-10 10:27     ` Pierre Gondois
2026-03-10 15:11       ` Qais Yousef
2026-03-10 16:59         ` Pierre Gondois
2026-03-12  8:19           ` Vincent Guittot

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=20251205125606.GA2528459@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bsegall@google.com \
    --cc=christian.loehle@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=hongyan.xia2@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luis.machado@arm.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=pierre.gondois@arm.com \
    --cc=qyousef@layalina.io \
    --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 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.