From: Andrea Righi <arighi@nvidia.com>
To: luoliang@kylinos.cn
Cc: Tejun Heo <tj@kernel.org>, David Vernet <void@manifault.com>,
Changwoo Min <changwoo@igalia.com>,
sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] sched_ext: Count cap-rejected local DSQ inserts in SCX_EV_SUB_REJECT
Date: Tue, 29 Sep 2026 07:09:55 +0200 [thread overview]
Message-ID: <artII3WkutGPf7VQ@gpd4> (raw)
In-Reply-To: <20260929030356.3454280-1-luoliang@kylinos.cn>
Hi Liang,
On Tue, Sep 29, 2026 at 11:03:56AM +0800, luoliang@kylinos.cn wrote:
> From: Liang Luo <luoliang@kylinos.cn>
>
> When a task is enqueued on a local DSQ without the caps its enqueue flags
> require, __scx_resolve_local_dsq() has three outcomes: admit the task
> anyway because the rq is draining offline, the task is migration-disabled
> or a migration is pending (counted in SCX_EV_SUB_FORCED_ADMIT), divert it
> to the rescue path when the enqueue requested rescue (counted in
> SCX_EV_SUB_RESCUE), or divert it to the reject DSQ to be re-enqueued so
> that the BPF scheduler can re-decide.
>
> Unlike the other two, which require a draining rq, a task that cannot
> migrate anywhere else, or an explicit SCX_ENQ_RESCUE opt-in, the reject
> diversion has no preconditions: every other cap-missing insert lands
> there. Its traffic is currently not visible in any counter -
> SCX_EV_REENQ_REPEAT only counts it once the same task fails its
> placement again, and nr_rejected counts tasks refused by ops.init_task()
> through task->scx.disallow.
>
> Add SCX_EV_SUB_REJECT and count the reject diversion so that the events
> cover all three outcomes of a cap-missing local insert.
I still don't see a need for this event. The BPF scheduler receives
SCX_TASK_REENQ_CAP on cap-related re-enqueues and can count those itself, as
scx_qmap already does. That count isn't identical to the proposed diversion
count, but the commit message doesn't explain why the distinction matters.
Is there a concrete case where this new counter would help diagnose a problem
that the scheduler-side count cannot?
Thanks,
-Andrea
>
> Signed-off-by: Liang Luo <luoliang@kylinos.cn>
>
> ---
>
> v2: Rework the rationale in the commit message and drop the Fixes: tag
> per Tejun. No code changes.
> ---
> kernel/sched/ext/internal.h | 10 +++++++++-
> kernel/sched/ext/sub.c | 2 ++
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/ext/internal.h b/kernel/sched/ext/internal.h
> index 0bcceab612de..36da1a6560db 100644
> --- a/kernel/sched/ext/internal.h
> +++ b/kernel/sched/ext/internal.h
> @@ -1308,6 +1308,13 @@ struct scx_event_stats {
> * caps for its cid and the task entered the rescue path.
> */
> s64 SCX_EV_SUB_RESCUE;
> +
> + /*
> + * The number of times an insert lacked the caps for its cid and was
> + * diverted to the reject DSQ to be re-enqueued so that the BPF
> + * scheduler can re-decide.
> + */
> + s64 SCX_EV_SUB_REJECT;
> };
>
> #define SCX_EVENTS_LIST(SCX_EVENT) \
> @@ -1331,7 +1338,8 @@ struct scx_event_stats {
> SCX_EVENT(SCX_EV_SUB_KICK_DENIED); \
> SCX_EVENT(SCX_EV_SUB_REENQ_DENIED); \
> SCX_EVENT(SCX_EV_SUB_CIDPERF_DENIED); \
> - SCX_EVENT(SCX_EV_SUB_RESCUE)
> + SCX_EVENT(SCX_EV_SUB_RESCUE); \
> + SCX_EVENT(SCX_EV_SUB_REJECT)
>
> struct scx_sched;
>
> diff --git a/kernel/sched/ext/sub.c b/kernel/sched/ext/sub.c
> index 10567196be96..3429b84f319a 100644
> --- a/kernel/sched/ext/sub.c
> +++ b/kernel/sched/ext/sub.c
> @@ -748,6 +748,8 @@ struct scx_dispatch_q *__scx_resolve_local_dsq(struct scx_sched *sch, struct rq
> return &rq->scx.rescue.dsq;
> }
>
> + __scx_add_event(sch, SCX_EV_SUB_REJECT, 1);
> +
> p->scx.reenq_reason_caps = missing;
> p->scx.reenq_reason_cid = cid;
>
> --
> 2.43.0
>
>
next prev parent reply other threads:[~2026-09-29 5:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 7:05 [PATCH] sched_ext: Count cap-rejected local DSQ inserts in SCX_EV_SUB_REJECT luoliang
2026-09-28 19:06 ` Tejun Heo
2026-09-29 3:00 ` luoliang
2026-09-29 3:03 ` [PATCH v2] " luoliang
2026-09-29 5:09 ` Andrea Righi [this message]
2026-09-29 6:12 ` luoliang
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=artII3WkutGPf7VQ@gpd4 \
--to=arighi@nvidia.com \
--cc=changwoo@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luoliang@kylinos.cn \
--cc=sched-ext@lists.linux.dev \
--cc=tj@kernel.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.