All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Righi <arighi@nvidia.com>
To: Tejun Heo <tj@kernel.org>
Cc: David Vernet <void@manifault.com>,
	Changwoo Min <changwoo@igalia.com>,
	sched-ext@lists.linux.dev, Emil Tsalapatis <emil@etsalapatis.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/6] sched_ext: Implement SCX_ENQ_IMMED
Date: Fri, 13 Mar 2026 20:15:42 +0100	[thread overview]
Message-ID: <abRiXpZBx0WC6pBz@gpd4> (raw)
In-Reply-To: <20260313113114.1591010-4-tj@kernel.org>

Hi Tejun,

On Fri, Mar 13, 2026 at 01:31:11AM -1000, Tejun Heo wrote:
> Add SCX_ENQ_IMMED enqueue flag for local DSQ insertions. Once a task is
> dispatched with IMMED, it either gets on the CPU immediately and stays on it,
> or gets reenqueued back to the BPF scheduler. It will never linger on a local
> DSQ behind other tasks or on a CPU taken by a higher-priority class.
> 
> rq_is_open() uses rq->next_class to determine whether the rq is available,
> and wakeup_preempt_scx() triggers reenqueue when a higher-priority class task
> arrives. These capture all higher class preemptions. Combined with reenqueue
> points in the dispatch path, all cases where an IMMED task would not execute
> immediately are covered.
> 
> SCX_TASK_IMMED persists in p->scx.flags until the next fresh enqueue, so the
> guarantee survives SAVE/RESTORE cycles. If preempted while running,
> put_prev_task_scx() reenqueues through ops.enqueue() with
> SCX_TASK_REENQ_PREEMPTED instead of silently placing the task back on the
> local DSQ.
> 
> This enables tighter scheduling latency control by preventing tasks from
> piling up on local DSQs. It also enables opportunistic CPU sharing across
> sub-schedulers - without this, a sub-scheduler can stuff the local DSQ of a
> shared CPU, making it difficult for others to use.
> 
> v2: - Rewrite is_curr_done() as rq_is_open() using rq->next_class and
>       implement wakeup_preempt_scx() to achieve complete coverage of all
>       cases where IMMED tasks could get stranded.
>     - Track IMMED persistently in p->scx.flags and reenqueue
>       preempted-while-running tasks through ops.enqueue().
>     - Bound deferred reenq cycles (SCX_REENQ_LOCAL_MAX_REPEAT).
>     - Misc renames, documentation.
> 
> Signed-off-by: Tejun Heo <tj@kernel.org>
...
> diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
> index 2f59265b9b57..85cdb65a5a66 100644
> --- a/kernel/sched/ext.c
> +++ b/kernel/sched/ext.c
> @@ -406,6 +406,62 @@ static bool bypass_dsp_enabled(struct scx_sched *sch)
>  	return unlikely(atomic_read(&sch->bypass_dsp_enable_depth));
>  }
>  
> +/**
> + * rq_is_open - Is the rq available for immediate execution of an SCX task?
> + * @rq: rq to test
> + * @enq_flags: optional %SCX_ENQ_* of the task being enqueued
> + *
> + * Returns %true if @rq is currently open for executing an SCX task. After a
> + * %false return, @rq is guaranateed to invoke SCX dispatch path at least once

nit: s/guaranateed/guaranteed/

Thanks,
-Andrea

  reply	other threads:[~2026-03-13 19:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-13 11:31 [PATCHSET v2 sched_ext/for-7.1] sched_ext: Implement SCX_ENQ_IMMED Tejun Heo
2026-03-13 11:31 ` [PATCH 1/6] sched_ext: Split task_should_reenq() into local and user variants Tejun Heo
2026-03-13 11:31 ` [PATCH 2/6] sched_ext: Add scx_vet_enq_flags() and plumb dsq_id into preamble Tejun Heo
2026-03-13 11:31 ` [PATCH 3/6] sched_ext: Implement SCX_ENQ_IMMED Tejun Heo
2026-03-13 19:15   ` Andrea Righi [this message]
2026-03-13 11:31 ` [PATCH 4/6] sched_ext: Plumb enq_flags through the consume path Tejun Heo
2026-03-13 11:31 ` [PATCH 5/6] sched_ext: Add enq_flags to scx_bpf_dsq_move_to_local() Tejun Heo
2026-03-13 11:31 ` [PATCH 6/6] sched_ext: Add SCX_OPS_ALWAYS_ENQ_IMMED ops flag Tejun Heo
2026-03-13 18:37 ` [PATCH 7/6 sched_ext/for-7.1] sched_ext: Use schedule_deferred_locked() in schedule_dsq_reenq() Tejun Heo
2026-03-13 19:21 ` [PATCHSET v2 sched_ext/for-7.1] sched_ext: Implement SCX_ENQ_IMMED Andrea Righi
2026-03-13 19: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=abRiXpZBx0WC6pBz@gpd4 \
    --to=arighi@nvidia.com \
    --cc=changwoo@igalia.com \
    --cc=emil@etsalapatis.com \
    --cc=linux-kernel@vger.kernel.org \
    --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.