mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Henry Huang" <henry.hj@antgroup.com>
To: tj@kernel.org, void@manifault.com
Cc: 谈鉴锋 <henry.tjf@antgroup.com>,
	"Yan Yan(cailing)" <yanyan.yan@antgroup.com>,
	linux-kernel@vger.kernel.org,
	"Henry Huang" <henry.hj@antgroup.com>
Subject: [PATCH v2] sched_ext: keep running prev when prev->scx.slice != 0
Date: Wed, 08 Jan 2025 16:47:09 +0800	[thread overview]
Message-ID: <20250108084710.42747-1-henry.hj@antgroup.com> (raw)

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.

For v2:
- set %SCX_RQ_BAL_KEEP in dispatch loop.
- cache prev->scx.flags & SCX_TASK_QUEUED result.

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

 kernel/sched/ext.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

-- 
Henry


             reply	other threads:[~2025-01-08  8:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-08  8:47 Henry Huang [this message]
2025-01-08  8:47 ` Henry Huang
2025-01-08 16:45   ` Tejun Heo

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=20250108084710.42747-1-henry.hj@antgroup.com \
    --to=henry.hj@antgroup.com \
    --cc=henry.tjf@antgroup.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=void@manifault.com \
    --cc=yanyan.yan@antgroup.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

all inboxes | Powered by JetHome®