From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
<linux-kernel@vger.kernel.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>,
"Gautham R. Shenoy" <gautham.shenoy@amd.com>,
Swapnil Sapkal <swapnil.sapkal@amd.com>
Subject: Re: [RFC PATCH 1/5] sched/fair: Add push task framework
Date: Thu, 10 Apr 2025 20:55:39 +0530 [thread overview]
Message-ID: <d58c8e54-1eb0-4b71-bb19-a6737829a4aa@amd.com> (raw)
In-Reply-To: <20250410100022.GA30687@noisy.programming.kicks-ass.net>
Hello Peter,
Thank you for the review.
On 4/10/2025 3:30 PM, Peter Zijlstra wrote:
> On Wed, Apr 09, 2025 at 11:15:35AM +0000, K Prateek Nayak wrote:
>
>> +static void fair_add_pushable_task(struct rq *rq, struct task_struct *p)
>> +{
>> + if (fair_push_task(p)) {
>> + plist_del(&p->pushable_tasks, &rq->cfs.pushable_tasks);
>> + plist_node_init(&p->pushable_tasks, p->prio);
>
> I gotta aks, why do we care about ordering the push list on p->prio for
> fair?
This bit was carried over from Vincent's series. I assume it was
inspired by the RT, DL's push mechanism. Perhaps fair can get away with
MRU ordering similar to rq->cfs_tasks?
>
>> + plist_add(&p->pushable_tasks, &rq->cfs.pushable_tasks);
>> + }
>> +}
>> +
>> /*
>> * select_task_rq_fair: Select target runqueue for the waking task in domains
>> * that have the relevant SD flag set. In practice, this is SD_BALANCE_WAKE,
>
>> @@ -8914,6 +8978,12 @@ pick_next_task_fair(struct rq *rq, struct task_struct *prev, struct rq_flags *rf
>> put_prev_entity(cfs_rq, pse);
>> set_next_entity(cfs_rq, se);
>>
>> + /*
>> + * The previous task might be eligible for being pushed on
>> + * another cpu if it is still active.
>> + */
>> + fair_add_pushable_task(rq, prev);
>> +
>> __set_next_task_fair(rq, p, true);
So __set_next_task_fair() removes the current task from the pushable list
when it is picked ...
>> }
>>
>> @@ -8986,6 +9056,13 @@ static void put_prev_task_fair(struct rq *rq, struct task_struct *prev, struct t
>> cfs_rq = cfs_rq_of(se);
>> put_prev_entity(cfs_rq, se);
>> }
>> +
>> + /*
>> + * The previous task might be eligible for being pushed on another cpu
>> + * if it is still active.
>> + */
>> + fair_add_pushable_task(rq, prev);
>> +
>> }
>
> These two are tricky; while they will work with a push balance callback,
> they will cause some pain with pulling from the push lists; a-la
> newidle.
>
> Notably, we must be sure to check ->on_cpu.
... so we should be safe here. Other considerations are covered by
detach_task() but pushable task lists to only contain queued tasks
that can run on more than one CPU and Vincent was cautious enough to
place a bunch of WARN_ON_ONCE() in pick_next_pushable_fair_task() to
catch those cases :)
>
> Perhaps later patches add this, let me continue reading...
--
Thanks and Regards,
Prateek
next prev parent reply other threads:[~2025-04-10 15:25 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-09 11:15 [RFC PATCH 0/5] K Prateek Nayak
2025-04-09 11:15 ` [RFC PATCH 1/5] sched/fair: Add push task framework K Prateek Nayak
2025-04-10 10:00 ` Peter Zijlstra
2025-04-10 15:25 ` K Prateek Nayak [this message]
2025-04-09 11:15 ` [RFC PATCH 2/5] sched/fair: Introduce overloaded_mask in sched_domain_shared K Prateek Nayak
2025-04-10 10:03 ` Peter Zijlstra
2025-04-10 15:26 ` K Prateek Nayak
2025-04-09 11:15 ` [RFC PATCH 3/5] sched/fair: Update overloaded mask in presence of pushable task K Prateek Nayak
2025-04-14 2:28 ` Aaron Lu
2025-04-14 3:13 ` K Prateek Nayak
2025-04-21 5:20 ` Shrikanth Hegde
2025-04-21 5:54 ` K Prateek Nayak
2025-04-21 8:03 ` Shrikanth Hegde
2025-04-21 8:54 ` K Prateek Nayak
2025-04-09 11:15 ` [RFC PATCH 4/5] sched/fair: Rework inter-NUMA newidle balancing K Prateek Nayak
2025-04-10 10:14 ` Peter Zijlstra
2025-04-10 15:27 ` K Prateek Nayak
2025-04-09 11:15 ` [RFC PATCH 5/5] sched/fair: Proactive idle balance using push mechanism K Prateek Nayak
2025-04-10 10:29 ` Peter Zijlstra
2025-04-10 15:37 ` K Prateek Nayak
2025-04-09 11:17 ` [RFC PATCH 0/5] sched/fair: Idle and newidle balancing " K Prateek Nayak
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=d58c8e54-1eb0-4b71-bb19-a6737829a4aa@amd.com \
--to=kprateek.nayak@amd.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=gautham.shenoy@amd.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=swapnil.sapkal@amd.com \
--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.