From: Tejun Heo <tj@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, David Vernet <void@manifault.com>,
Ingo Molnar <mingo@redhat.com>,
Alexei Starovoitov <ast@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [GIT PULL] sched_ext: Initial pull request for v6.11
Date: Tue, 30 Jul 2024 15:36:27 -1000 [thread overview]
Message-ID: <ZqmVG9ZiktN6bnm0@slm.duckdns.org> (raw)
In-Reply-To: <20240724085221.GO26750@noisy.programming.kicks-ass.net>
Hello,
On Wed, Jul 24, 2024 at 10:52:21AM +0200, Peter Zijlstra wrote:
...
> So pick_task() came from the SCHED_CORE crud, which does a remote pick
> and as such isn't able to do a put -- remote is still running its
> current etc.
>
> So pick_task() *SHOULD* already be considering its current and pick
> that if it is a better candidate than whatever is on the queue.
>
> If we have a pick_task() that doesn't do that, it's a pre-existing bug
> and needs fixing anyhow.
Right, I don't think it affects SCX in any significant way. Either way
should be fine.
...
> > Yeah, this came up before. On UP, SCX either needs to call the balance
> > callback as that's where the whole dispatch logic is called from (which
> > makes sense for it as dispatching often involves balancing operations), or
> > SCX itself needs to call it directly in a matching sequence. Just enabling
> > balance callback on UP && SCX would be the cleanest.
>
> Or make scx hard depend on SMP? Are there really still people using !SMP
> -- and I suppose more importantly, do we care?
>
> I mean, they could always run an SMP kernel on their UP potato if they
> *really* feel they need this.
Maybe, but at the same time, it's also just some isolated cruft that enables
UP support, so both sides of the scale seem similarly light-weight? I lean
towards "why not support it?" but don't feel particularly strongly about it.
Thanks.
--
tejun
next prev parent reply other threads:[~2024-07-31 1:36 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-15 22:32 [GIT PULL] sched_ext: Initial pull request for v6.11 Tejun Heo
2024-07-23 16:33 ` Peter Zijlstra
2024-07-23 19:34 ` Tejun Heo
2024-07-24 8:52 ` Peter Zijlstra
2024-07-24 17:38 ` David Vernet
2024-07-31 1:36 ` Tejun Heo [this message]
2024-08-02 11:10 ` Peter Zijlstra
2024-08-02 16:09 ` Tejun Heo
2024-08-02 17:37 ` Peter Zijlstra
2024-08-06 21:10 ` Peter Zijlstra
2024-08-06 21:34 ` Tejun Heo
2024-08-06 21:55 ` Peter Zijlstra
2024-08-06 22:09 ` Tejun Heo
2024-08-10 20:45 ` Peter Zijlstra
2024-08-13 19:14 ` Tejun Heo
2024-08-13 22:53 ` Peter Zijlstra
2024-08-21 23:08 ` Tejun Heo
2024-08-06 19:56 ` Tejun Heo
2024-08-06 20:18 ` Peter Zijlstra
2024-08-06 20:20 ` Tejun Heo
2024-08-02 12:20 ` Peter Zijlstra
2024-08-02 18:47 ` Tejun Heo
2024-08-06 8:27 ` Peter Zijlstra
2024-08-06 19:17 ` Tejun Heo
2024-07-25 1:19 ` Qais Yousef
2024-07-30 9:04 ` Peter Zijlstra
2024-07-31 1:11 ` Tejun Heo
2024-07-31 1:22 ` Tejun Heo
2024-08-01 13:17 ` Qais Yousef
2024-08-01 16:36 ` Tejun Heo
2024-08-05 1:44 ` Qais Yousef
2024-08-01 2:50 ` Russell Haley
2024-08-01 15:52 ` Qais Yousef
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=ZqmVG9ZiktN6bnm0@slm.duckdns.org \
--to=tj@kernel.org \
--cc=ast@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--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 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.