public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: void@manifault.com, linux-kernel@vger.kernel.org,
	kernel-team@meta.com, sched-ext@meta.com, peterz@infradead.org,
	Pat Somaru <patso@likewhatevs.io>
Subject: Re: [PATCH sched_ext/for-6.12-fixes] Disable SM_IDLE/rq empty path when scx_enabled
Date: Tue, 24 Sep 2024 12:21:06 -1000	[thread overview]
Message-ID: <ZvM7UntdPJKioomO@slm.duckdns.org> (raw)
In-Reply-To: <3e6fdedc-a87c-ff8a-a75c-5c1282a122b5@amd.com>

Hello,

On Tue, Sep 24, 2024 at 09:10:02AM +0530, K Prateek Nayak wrote:
> >   	prev_state = READ_ONCE(prev->__state);
> >   	if (sched_mode == SM_IDLE) {
> > -		if (!rq->nr_running) {
> > +		/* SCX must consult the BPF scheduler to tell if rq is empty */
> 
> I was wondering if sched_ext case could simply do:
> 
> 		if (scx_enabled())
> 			prev_balance(rq, prev, rf);
> 
> and use "rq->scx.flags" to skip balancing in balance_scx() later when
> __pick_next_task() calls prev_balance() but (and please correct me if
> I'm wrong here) balance_scx() calls balance_one() which can call
> consume_dispatch_q() to pick a task from global / user-defined dispatch
> queue, and in doing so, it does not update "rq->nr_running".

Hmm... would that be a meaningful optimization? prev_balance() calls into
SCX's dispatch path and there can be quite a bit going on there. I'm not
sure whether it'd worth much to save a trip through __pick_next_task().

> I could only see add_nr_running() being called from enqueue_task_scx()
> and this is even before the ext core calls do_enqueue_task() which hooks
> into the bpf layer which makes the decision where the task actually
> goes.
> 
> Is my understanding correct that whichever CPU is the target for the
> enqueue_task_scx() callback initially is the one that accounts the
> enqueue in "rq->nr_running" until the task is dequeued or did I miss
> something?

Whenever a task is dispatched to a local DSQ of a CPU including from
balance_one(), if the task is not on that CPU already,
move_remote_task_to_local_dsq() is called which migrates the task to the
target CPU by deactivating and then re-activating it. As deactivating and
re-activating involves dequeueing and re-enqueueing, rq->running gets
updated accordingly.

Thanks.

-- 
tejun

  reply	other threads:[~2024-09-24 22:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-20 19:41 [PATCH sched_ext/for-6.12-fixes] Disable SM_IDLE/rq empty path when scx_enabled Pat Somaru
2024-09-23 15:43 ` Tejun Heo
2024-09-24  3:40   ` K Prateek Nayak
2024-09-24 22:21     ` Tejun Heo [this message]
2024-09-25  3:17       ` 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=ZvM7UntdPJKioomO@slm.duckdns.org \
    --to=tj@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patso@likewhatevs.io \
    --cc=peterz@infradead.org \
    --cc=sched-ext@meta.com \
    --cc=void@manifault.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