linux-kernel - [PATCH v1] sched_ext: keep running prev when prev->scx.slice != 0

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-next>] [day] [month] [year] [list]

Message-ID: <20250107042555.67051-1-henry.hj@antgroup.com>
Date: Tue, 07 Jan 2025 12:25:54 +0800
From: "Henry Huang" <henry.hj@...group.com>
To: tj@...nel.org,
	void@...ifault.com
Cc: "谈鉴锋" <henry.tjf@...group.com>,
  "Yan Yan(cailing)" <yanyan.yan@...group.com>,
   <linux-kernel@...r.kernel.org>,
  "Henry Huang" <henry.hj@...group.com>
Subject: [PATCH v1] sched_ext: keep running prev when prev->scx.slice != 0

In our environment, we have various types of tasks. Some tasks can keep running after their slice is exhausted,
while others need to be dispatched into the global DSQ for rescheduling. Therefore, we set %SCX_OPS_ENQ_LAST.

However, we encountered a problem:
Because put_prev_task_scx() is executed after pick_task_scx(), @prev only has the opportunity to be dispatched
into local DSQ in put_prev_task_scx(). Since pick_task_scx returns NULL, the CPU enters the idle state instead of running @prev.

Our current workaround is to set a value to @prev->scx.slice in ops.dispatch() and call scx_bpf_kick_cpu(cpu, 0) to trigger a reschedule.
Of course, this approach introduces some overhead.

Our solution:
When %SCX_OPS_ENQ_LAST is set and prev->scx.slice != 0, we only need to set %SCX_RQ_BAL_KEEP in blance_one to
ensure pick_task_scx() can pick the correct task.

Henry Huang (1):
  sched_ext: keep running prev when prev->scx.slice != 0

 kernel/sched/ext.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

-- 
1.8.3.1