linux-kernel - Re: [PATCH 12/36] sched_ext: Implement BPF extensible scheduler class

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 23 Mar 2024 12:12:31 -1000
From: Tejun Heo <tj@...nel.org>
To: Joel Fernandes <joel@...lfernandes.org>
Cc: torvalds@...ux-foundation.org, mingo@...hat.com, peterz@...radead.org,
	juri.lelli@...hat.com, vincent.guittot@...aro.org,
	dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
	mgorman@...e.de, bristot@...hat.com, vschneid@...hat.com,
	ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
	martin.lau@...nel.org, joshdon@...gle.com, brho@...gle.com,
	pjt@...gle.com, derkling@...gle.com, haoluo@...gle.com,
	dvernet@...a.com, dschatzberg@...a.com, dskarlat@...cmu.edu,
	riel@...riel.com, changwoo@...lia.com, himadrics@...ia.fr,
	memxor@...il.com, linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
	kernel-team@...a.com, Andrea Righi <andrea.righi@...onical.com>
Subject: Re: [PATCH 12/36] sched_ext: Implement BPF extensible scheduler class

Hello, Joel.

On Fri, Mar 22, 2024 at 10:37:32PM -0400, Joel Fernandes wrote:
..
> I was wondering about the comment above related to 'wakeup_preempt', could
> you clarify why it is not useful (NOOP) in the sched-ext class?
> 
> wakeup_preempt() may be called via:
> sched_ttwu_pending() ->
> 	ttwu_do_activate() ->
> 		wakeup_preempt()
> 			
> 
> at which point the enqueue of the task could have already happened via:
> 
> sched_ttwu_pending() ->
> 	ttwu_do_activate() ->
> 		activate_task() ->
> 			enqueue_task()
> 
> But the comment above says "task isn't tied to the CPU" ?

In sched_ext, a scheduling queue isn't tied to a particular CPU. For
example, it's trivial to share a single global scheduling queue across the
whole system or any subset of CPUs. To support this behavior, tasks can be
hot-migrated in the dispatch path just before it starts executing:

 https://github.com/sched-ext/sched_ext/blob/sched_ext/kernel/sched/ext.c#L1335  

So, the CPU picked by ops.select_cpu() in the enqueue path often doesn't
determine the CPU the task is going to execute on. If the picked CPU matches
the CPU the task is eventually going to run on, there's a small performance
advantage as the later hot migration can be avoided.

As the task isn't actually tied to the CPU being picked, it's a bit awkward
to ask "does this task preempt this CPU?" Instead, preemption is implemented
by calling scx_bpf_kick_cpu() w/ SCX_KICK_PREEMPT or using the
SCX_ENQ_PREEMPT flag from the enqueue path which allows preempting any CPU.

> Apologies in advance if I missed something as I just recently starting
> looking into the sched-ext patches.

No worries. Happy to answer any questions.

Thanks.

-- 
tejun