[PATCH 0/2] sched_ext: Add a core event and update scx schedulers

[PATCH 0/2] sched_ext: Add a core event and update scx schedulers

[Changwoo Min]

This patchset introduces a new event, SCX_EV_ENQ_SLICE_DFL, and updates
two scx schedulers -- scx_qmap and scx_central -- to print out the new
event.

SCX_EV_ENQ_SLICE_DFL counts how many times the tasks' time slice is set
to the default value (SCX_SLICE_DFL) by the sched_ext core in the enqueue
and pick_next paths.

Scheduling a task with SCX_SLICE_DFL unintentionally would be a source
of latency spikes because SCX_SLICE_DFL is relatively long (20 msec).
Thus, soaring the SCX_EV_ENQ_SLICE_DFL value would be a sign of BPF
scheduler bugs, causing latency spikes.

Changwoo Min (2):
  sched_ext: Add an event, SCX_EV_ENQ_SLICE_DFL
  sched_ext: Print an event, SCX_EV_ENQ_SLICE_DFL, in scx_qmap/central

 kernel/sched/ext.c                | 15 ++++++++++++++-
 tools/sched_ext/scx_central.bpf.c |  2 ++
 tools/sched_ext/scx_qmap.bpf.c    |  2 ++
 3 files changed, 18 insertions(+), 1 deletion(-)

-- 
2.48.1

[PATCH 1/2] sched_ext: Add an event, SCX_EV_ENQ_SLICE_DFL

[Changwoo Min]

Add a core event, SCX_EV_ENQ_SLICE_DFL, which represents how many
tasks have been enqueued (or pick_task-ed) with a default time slice
(SCX_SLICE_DFL).

Scheduling a task with SCX_SLICE_DFL unintentionally would be a source
of latency spikes because SCX_SLICE_DFL is relatively long (20 msec).
Thus, soaring the SCX_EV_ENQ_SLICE_DFL value would be a sign of BPF
scheduler bugs, causing latency spikes.

__scx_add_event() is used since the caller holds an rq lock,
so the preemption has already been disabled.

Signed-off-by: Changwoo Min <changwoo@igalia.com>
---
 kernel/sched/ext.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
index 8a9a30895381..1077df9280bb 100644
--- a/kernel/sched/ext.c
+++ b/kernel/sched/ext.c
@@ -1468,6 +1468,12 @@ struct scx_event_stats {
 	 */
 	u64		SCX_EV_ENQ_SKIP_EXITING;
 
+	/*
+	 * The total number of tasks enqueued (or pick_task-ed) with a
+	 * default time slice (SCX_SLICE_DFL).
+	 */
+	u64		SCX_EV_ENQ_SLICE_DFL;
+
 	/*
 	 * The total duration of bypass modes in nanoseconds.
 	 */
@@ -2134,6 +2140,7 @@ static void do_enqueue_task(struct rq *rq, struct task_struct *p, u64 enq_flags,
 	 */
 	touch_core_sched(rq, p);
 	p->scx.slice = SCX_SLICE_DFL;
+	__scx_add_event(SCX_EV_ENQ_SLICE_DFL, 1);
 local_norefill:
 	dispatch_enqueue(&rq->scx.local_dsq, p, enq_flags);
 	return;
@@ -2141,6 +2148,7 @@ static void do_enqueue_task(struct rq *rq, struct task_struct *p, u64 enq_flags,
 global:
 	touch_core_sched(rq, p);	/* see the comment in local: */
 	p->scx.slice = SCX_SLICE_DFL;
+	__scx_add_event(SCX_EV_ENQ_SLICE_DFL, 1);
 	dispatch_enqueue(find_global_dsq(p), p, enq_flags);
 }
 
@@ -3202,8 +3210,10 @@ static struct task_struct *pick_task_scx(struct rq *rq)
 	 */
 	if (keep_prev) {
 		p = prev;
-		if (!p->scx.slice)
+		if (!p->scx.slice) {
 			p->scx.slice = SCX_SLICE_DFL;
+			__scx_add_event(SCX_EV_ENQ_SLICE_DFL, 1);
+		}
 	} else {
 		p = first_local_task(rq);
 		if (!p) {
@@ -3219,6 +3229,7 @@ static struct task_struct *pick_task_scx(struct rq *rq)
 				scx_warned_zero_slice = true;
 			}
 			p->scx.slice = SCX_SLICE_DFL;
+			__scx_add_event(SCX_EV_ENQ_SLICE_DFL, 1);
 		}
 	}
 
@@ -5023,6 +5034,7 @@ static void scx_dump_state(struct scx_exit_info *ei, size_t dump_len)
 	scx_dump_event(s, &events, SCX_EV_DISPATCH_LOCAL_DSQ_OFFLINE);
 	scx_dump_event(s, &events, SCX_EV_DISPATCH_KEEP_LAST);
 	scx_dump_event(s, &events, SCX_EV_ENQ_SKIP_EXITING);
+	scx_dump_event(s, &events, SCX_EV_ENQ_SLICE_DFL);
 	scx_dump_event(s, &events, SCX_EV_BYPASS_DURATION);
 	scx_dump_event(s, &events, SCX_EV_BYPASS_DISPATCH);
 	scx_dump_event(s, &events, SCX_EV_BYPASS_ACTIVATE);
@@ -7163,6 +7175,7 @@ __bpf_kfunc void scx_bpf_events(struct scx_event_stats *events,
 		scx_agg_event(&e_sys, e_cpu, SCX_EV_DISPATCH_LOCAL_DSQ_OFFLINE);
 		scx_agg_event(&e_sys, e_cpu, SCX_EV_DISPATCH_KEEP_LAST);
 		scx_agg_event(&e_sys, e_cpu, SCX_EV_ENQ_SKIP_EXITING);
+		scx_agg_event(&e_sys, e_cpu, SCX_EV_ENQ_SLICE_DFL);
 		scx_agg_event(&e_sys, e_cpu, SCX_EV_BYPASS_DURATION);
 		scx_agg_event(&e_sys, e_cpu, SCX_EV_BYPASS_DISPATCH);
 		scx_agg_event(&e_sys, e_cpu, SCX_EV_BYPASS_ACTIVATE);
-- 
2.48.1

Re: [PATCH 1/2] sched_ext: Add an event, SCX_EV_ENQ_SLICE_DFL

[Andrea Righi]

Hi Changwoo,

On Fri, Feb 07, 2025 at 12:13:37PM +0900, Changwoo Min wrote:
> Add a core event, SCX_EV_ENQ_SLICE_DFL, which represents how many
> tasks have been enqueued (or pick_task-ed) with a default time slice
> (SCX_SLICE_DFL).
> 
> Scheduling a task with SCX_SLICE_DFL unintentionally would be a source
> of latency spikes because SCX_SLICE_DFL is relatively long (20 msec).
> Thus, soaring the SCX_EV_ENQ_SLICE_DFL value would be a sign of BPF
> scheduler bugs, causing latency spikes.
> 
> __scx_add_event() is used since the caller holds an rq lock,
> so the preemption has already been disabled.

We may want to consider select_task_rq_scx() as well, when ops.select_cpu()
is not implemented (or during rq_bypass).

In this case, if scx_select_cpu_dfl() finds an idle CPU, we implicitly
dispatch the task to the local DSQ with SCX_SLICE_DFL.

Thanks,
-Andrea

> 
> Signed-off-by: Changwoo Min <changwoo@igalia.com>
> ---
>  kernel/sched/ext.c | 15 ++++++++++++++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
> index 8a9a30895381..1077df9280bb 100644
> --- a/kernel/sched/ext.c
> +++ b/kernel/sched/ext.c
> @@ -1468,6 +1468,12 @@ struct scx_event_stats {
>  	 */
>  	u64		SCX_EV_ENQ_SKIP_EXITING;
>  
> +	/*
> +	 * The total number of tasks enqueued (or pick_task-ed) with a
> +	 * default time slice (SCX_SLICE_DFL).
> +	 */
> +	u64		SCX_EV_ENQ_SLICE_DFL;
> +
>  	/*
>  	 * The total duration of bypass modes in nanoseconds.
>  	 */
> @@ -2134,6 +2140,7 @@ static void do_enqueue_task(struct rq *rq, struct task_struct *p, u64 enq_flags,
>  	 */
>  	touch_core_sched(rq, p);
>  	p->scx.slice = SCX_SLICE_DFL;
> +	__scx_add_event(SCX_EV_ENQ_SLICE_DFL, 1);
>  local_norefill:
>  	dispatch_enqueue(&rq->scx.local_dsq, p, enq_flags);
>  	return;
> @@ -2141,6 +2148,7 @@ static void do_enqueue_task(struct rq *rq, struct task_struct *p, u64 enq_flags,
>  global:
>  	touch_core_sched(rq, p);	/* see the comment in local: */
>  	p->scx.slice = SCX_SLICE_DFL;
> +	__scx_add_event(SCX_EV_ENQ_SLICE_DFL, 1);
>  	dispatch_enqueue(find_global_dsq(p), p, enq_flags);
>  }
>  
> @@ -3202,8 +3210,10 @@ static struct task_struct *pick_task_scx(struct rq *rq)
>  	 */
>  	if (keep_prev) {
>  		p = prev;
> -		if (!p->scx.slice)
> +		if (!p->scx.slice) {
>  			p->scx.slice = SCX_SLICE_DFL;
> +			__scx_add_event(SCX_EV_ENQ_SLICE_DFL, 1);
> +		}
>  	} else {
>  		p = first_local_task(rq);
>  		if (!p) {
> @@ -3219,6 +3229,7 @@ static struct task_struct *pick_task_scx(struct rq *rq)
>  				scx_warned_zero_slice = true;
>  			}
>  			p->scx.slice = SCX_SLICE_DFL;
> +			__scx_add_event(SCX_EV_ENQ_SLICE_DFL, 1);
>  		}
>  	}
>  
> @@ -5023,6 +5034,7 @@ static void scx_dump_state(struct scx_exit_info *ei, size_t dump_len)
>  	scx_dump_event(s, &events, SCX_EV_DISPATCH_LOCAL_DSQ_OFFLINE);
>  	scx_dump_event(s, &events, SCX_EV_DISPATCH_KEEP_LAST);
>  	scx_dump_event(s, &events, SCX_EV_ENQ_SKIP_EXITING);
> +	scx_dump_event(s, &events, SCX_EV_ENQ_SLICE_DFL);
>  	scx_dump_event(s, &events, SCX_EV_BYPASS_DURATION);
>  	scx_dump_event(s, &events, SCX_EV_BYPASS_DISPATCH);
>  	scx_dump_event(s, &events, SCX_EV_BYPASS_ACTIVATE);
> @@ -7163,6 +7175,7 @@ __bpf_kfunc void scx_bpf_events(struct scx_event_stats *events,
>  		scx_agg_event(&e_sys, e_cpu, SCX_EV_DISPATCH_LOCAL_DSQ_OFFLINE);
>  		scx_agg_event(&e_sys, e_cpu, SCX_EV_DISPATCH_KEEP_LAST);
>  		scx_agg_event(&e_sys, e_cpu, SCX_EV_ENQ_SKIP_EXITING);
> +		scx_agg_event(&e_sys, e_cpu, SCX_EV_ENQ_SLICE_DFL);
>  		scx_agg_event(&e_sys, e_cpu, SCX_EV_BYPASS_DURATION);
>  		scx_agg_event(&e_sys, e_cpu, SCX_EV_BYPASS_DISPATCH);
>  		scx_agg_event(&e_sys, e_cpu, SCX_EV_BYPASS_ACTIVATE);
> -- 
> 2.48.1
> 

Re: [PATCH 1/2] sched_ext: Add an event, SCX_EV_ENQ_SLICE_DFL

[Changwoo Min]

Hi Andrea,

On 25. 2. 7. 15:17, Andrea Righi wrote:
> Hi Changwoo,
> 
> On Fri, Feb 07, 2025 at 12:13:37PM +0900, Changwoo Min wrote:
>> Add a core event, SCX_EV_ENQ_SLICE_DFL, which represents how many
>> tasks have been enqueued (or pick_task-ed) with a default time slice
>> (SCX_SLICE_DFL).
>>
>> Scheduling a task with SCX_SLICE_DFL unintentionally would be a source
>> of latency spikes because SCX_SLICE_DFL is relatively long (20 msec).
>> Thus, soaring the SCX_EV_ENQ_SLICE_DFL value would be a sign of BPF
>> scheduler bugs, causing latency spikes.
>>
>> __scx_add_event() is used since the caller holds an rq lock,
>> so the preemption has already been disabled.
> 
> We may want to consider select_task_rq_scx() as well, when ops.select_cpu()
> is not implemented (or during rq_bypass).
> 
> In this case, if scx_select_cpu_dfl() finds an idle CPU, we implicitly
> dispatch the task to the local DSQ with SCX_SLICE_DFL.

You are right. I will add it too.

Thanks!
-- Changwoo

[PATCH 2/2] sched_ext: Print an event, SCX_EV_ENQ_SLICE_DFL, in scx_qmap/central

[Changwoo Min]

Modify the scx_qmap and scx_celtral schedulers
to print the SCX_EV_ENQ_SLICE_DFL event every second.

Signed-off-by: Changwoo Min <changwoo@igalia.com>
---
 tools/sched_ext/scx_central.bpf.c | 2 ++
 tools/sched_ext/scx_qmap.bpf.c    | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/tools/sched_ext/scx_central.bpf.c b/tools/sched_ext/scx_central.bpf.c
index 376c14d5dd0d..907a844723c1 100644
--- a/tools/sched_ext/scx_central.bpf.c
+++ b/tools/sched_ext/scx_central.bpf.c
@@ -305,6 +305,8 @@ static int central_timerfn(void *map, int *key, struct bpf_timer *timer)
 			   scx_read_event(&events, SCX_EV_DISPATCH_KEEP_LAST));
 		bpf_printk("%35s: %llu\n", "SCX_EV_ENQ_SKIP_EXITING",
 			   scx_read_event(&events, SCX_EV_ENQ_SKIP_EXITING));
+		bpf_printk("%35s: %llu\n", "SCX_EV_ENQ_SLICE_DFL",
+			   scx_read_event(&events, SCX_EV_ENQ_SLICE_DFL));
 		bpf_printk("%35s: %llu\n", "SCX_EV_BYPASS_DURATION",
 			   scx_read_event(&events, SCX_EV_BYPASS_DURATION));
 		bpf_printk("%35s: %llu\n", "SCX_EV_BYPASS_DISPATCH",
diff --git a/tools/sched_ext/scx_qmap.bpf.c b/tools/sched_ext/scx_qmap.bpf.c
index 5edb79742e37..7d9d1e5d2358 100644
--- a/tools/sched_ext/scx_qmap.bpf.c
+++ b/tools/sched_ext/scx_qmap.bpf.c
@@ -784,6 +784,8 @@ static int monitor_timerfn(void *map, int *key, struct bpf_timer *timer)
 		   scx_read_event(&events, SCX_EV_DISPATCH_KEEP_LAST));
 	bpf_printk("%35s: %llu\n", "SCX_EV_ENQ_SKIP_EXITING",
 		   scx_read_event(&events, SCX_EV_ENQ_SKIP_EXITING));
+	bpf_printk("%35s: %llu\n", "SCX_EV_ENQ_SLICE_DFL",
+		   scx_read_event(&events, SCX_EV_ENQ_SLICE_DFL));
 	bpf_printk("%35s: %llu\n", "SCX_EV_BYPASS_DURATION",
 		   scx_read_event(&events, SCX_EV_BYPASS_DURATION));
 	bpf_printk("%35s: %llu\n", "SCX_EV_BYPASS_DISPATCH",
-- 
2.48.1

Re: [PATCH 0/2] sched_ext: Add a core event and update scx schedulers

[Andrea Righi]

Hi,

On Fri, Feb 07, 2025 at 12:13:36PM +0900, Changwoo Min wrote:
> This patchset introduces a new event, SCX_EV_ENQ_SLICE_DFL, and updates
> two scx schedulers -- scx_qmap and scx_central -- to print out the new
> event.
> 
> SCX_EV_ENQ_SLICE_DFL counts how many times the tasks' time slice is set
> to the default value (SCX_SLICE_DFL) by the sched_ext core in the enqueue
> and pick_next paths.
> 
> Scheduling a task with SCX_SLICE_DFL unintentionally would be a source
> of latency spikes because SCX_SLICE_DFL is relatively long (20 msec).
> Thus, soaring the SCX_EV_ENQ_SLICE_DFL value would be a sign of BPF
> scheduler bugs, causing latency spikes.

Not directly related to this patch set, but as a general thought: would it
be useful to introduce ops->slice_ms (in sched_ext_ops) to override
SCX_SLICE_DFL?

With that, schedulers that care about latency could set a smaller default
time slice to prevent potential spikes caused by the implicit use of
SCX_SLICE_DFL.

Opinions?

-Andrea

> 
> Changwoo Min (2):
>   sched_ext: Add an event, SCX_EV_ENQ_SLICE_DFL
>   sched_ext: Print an event, SCX_EV_ENQ_SLICE_DFL, in scx_qmap/central
> 
>  kernel/sched/ext.c                | 15 ++++++++++++++-
>  tools/sched_ext/scx_central.bpf.c |  2 ++
>  tools/sched_ext/scx_qmap.bpf.c    |  2 ++
>  3 files changed, 18 insertions(+), 1 deletion(-)
> 
> -- 
> 2.48.1
> 

Re: [PATCH 0/2] sched_ext: Add a core event and update scx schedulers

[Changwoo Min]

Hello,

On 25. 2. 7. 15:24, Andrea Righi wrote:
> Hi,
> 
> On Fri, Feb 07, 2025 at 12:13:36PM +0900, Changwoo Min wrote:
>> This patchset introduces a new event, SCX_EV_ENQ_SLICE_DFL, and updates
>> two scx schedulers -- scx_qmap and scx_central -- to print out the new
>> event.
>>
>> SCX_EV_ENQ_SLICE_DFL counts how many times the tasks' time slice is set
>> to the default value (SCX_SLICE_DFL) by the sched_ext core in the enqueue
>> and pick_next paths.
>>
>> Scheduling a task with SCX_SLICE_DFL unintentionally would be a source
>> of latency spikes because SCX_SLICE_DFL is relatively long (20 msec).
>> Thus, soaring the SCX_EV_ENQ_SLICE_DFL value would be a sign of BPF
>> scheduler bugs, causing latency spikes.
> 
> Not directly related to this patch set, but as a general thought: would it
> be useful to introduce ops->slice_ms (in sched_ext_ops) to override
> SCX_SLICE_DFL?
> 
> With that, schedulers that care about latency could set a smaller default
> time slice to prevent potential spikes caused by the implicit use of
> SCX_SLICE_DFL.
> 
> Opinions?

That sounds like a good idea!

Regards,
Changwoo Min

Re: [PATCH 0/2] sched_ext: Add a core event and update scx schedulers

[Andrea Righi]

On Fri, Feb 07, 2025 at 03:49:24PM +0900, Changwoo Min wrote:
> Hello,
> 
> On 25. 2. 7. 15:24, Andrea Righi wrote:
> > Hi,
> > 
> > On Fri, Feb 07, 2025 at 12:13:36PM +0900, Changwoo Min wrote:
> > > This patchset introduces a new event, SCX_EV_ENQ_SLICE_DFL, and updates
> > > two scx schedulers -- scx_qmap and scx_central -- to print out the new
> > > event.
> > > 
> > > SCX_EV_ENQ_SLICE_DFL counts how many times the tasks' time slice is set
> > > to the default value (SCX_SLICE_DFL) by the sched_ext core in the enqueue
> > > and pick_next paths.
> > > 
> > > Scheduling a task with SCX_SLICE_DFL unintentionally would be a source
> > > of latency spikes because SCX_SLICE_DFL is relatively long (20 msec).
> > > Thus, soaring the SCX_EV_ENQ_SLICE_DFL value would be a sign of BPF
> > > scheduler bugs, causing latency spikes.
> > 
> > Not directly related to this patch set, but as a general thought: would it
> > be useful to introduce ops->slice_ms (in sched_ext_ops) to override
> > SCX_SLICE_DFL?
> > 
> > With that, schedulers that care about latency could set a smaller default
> > time slice to prevent potential spikes caused by the implicit use of
> > SCX_SLICE_DFL.
> > 
> > Opinions?
> 
> That sounds like a good idea!

Alright, I'll send a patch after this one is applied.

Thanks,
-Andrea

> 
> Regards,
> Changwoo Min

Re: [PATCH 0/2] sched_ext: Add a core event and update scx schedulers

[Tejun Heo]

Hello,

On Fri, Feb 07, 2025 at 07:24:08AM +0100, Andrea Righi wrote:
> On Fri, Feb 07, 2025 at 12:13:36PM +0900, Changwoo Min wrote:
> > This patchset introduces a new event, SCX_EV_ENQ_SLICE_DFL, and updates
> > two scx schedulers -- scx_qmap and scx_central -- to print out the new
> > event.
> > 
> > SCX_EV_ENQ_SLICE_DFL counts how many times the tasks' time slice is set
> > to the default value (SCX_SLICE_DFL) by the sched_ext core in the enqueue
> > and pick_next paths.
> > 
> > Scheduling a task with SCX_SLICE_DFL unintentionally would be a source
> > of latency spikes because SCX_SLICE_DFL is relatively long (20 msec).
> > Thus, soaring the SCX_EV_ENQ_SLICE_DFL value would be a sign of BPF
> > scheduler bugs, causing latency spikes.
> 
> Not directly related to this patch set, but as a general thought: would it
> be useful to introduce ops->slice_ms (in sched_ext_ops) to override
> SCX_SLICE_DFL?
> 
> With that, schedulers that care about latency could set a smaller default
> time slice to prevent potential spikes caused by the implicit use of
> SCX_SLICE_DFL.
> 
> Opinions?

I'm not sure. BPF schedulers should be able to avoid getting the default
slice. Hopefully, with the added visibility, this should be easier now. I'm
not sure how much overriding the default value in ops helps in terms of
control. It's a very half-way measure. Instead, how about we add tracepoint
to scx_add_event() so that folks who want to get backtrace of specific
events can get them easily so that it's easier to debug where these counts
are coming from? Let's just make it easier to avoid these events.

Thanks.

-- 
tejun

Re: [PATCH 0/2] sched_ext: Add a core event and update scx schedulers

[Andrea Righi]

On Fri, Feb 07, 2025 at 11:38:31AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Fri, Feb 07, 2025 at 07:24:08AM +0100, Andrea Righi wrote:
> > On Fri, Feb 07, 2025 at 12:13:36PM +0900, Changwoo Min wrote:
> > > This patchset introduces a new event, SCX_EV_ENQ_SLICE_DFL, and updates
> > > two scx schedulers -- scx_qmap and scx_central -- to print out the new
> > > event.
> > > 
> > > SCX_EV_ENQ_SLICE_DFL counts how many times the tasks' time slice is set
> > > to the default value (SCX_SLICE_DFL) by the sched_ext core in the enqueue
> > > and pick_next paths.
> > > 
> > > Scheduling a task with SCX_SLICE_DFL unintentionally would be a source
> > > of latency spikes because SCX_SLICE_DFL is relatively long (20 msec).
> > > Thus, soaring the SCX_EV_ENQ_SLICE_DFL value would be a sign of BPF
> > > scheduler bugs, causing latency spikes.
> > 
> > Not directly related to this patch set, but as a general thought: would it
> > be useful to introduce ops->slice_ms (in sched_ext_ops) to override
> > SCX_SLICE_DFL?
> > 
> > With that, schedulers that care about latency could set a smaller default
> > time slice to prevent potential spikes caused by the implicit use of
> > SCX_SLICE_DFL.
> > 
> > Opinions?
> 
> I'm not sure. BPF schedulers should be able to avoid getting the default
> slice. Hopefully, with the added visibility, this should be easier now. I'm
> not sure how much overriding the default value in ops helps in terms of
> control. It's a very half-way measure. Instead, how about we add tracepoint
> to scx_add_event() so that folks who want to get backtrace of specific
> events can get them easily so that it's easier to debug where these counts
> are coming from? Let's just make it easier to avoid these events.

Yeah, that's a valid point, the implicit SCX_SLICE_DFL should be seen as a
countermeasure for unhandled situations. Instead of fixing the
countermeasure itself we should try to prevent it, if it proves to be
problematic. And I like the idea of having a way to backtrace specific
events.

-Andrea

Re: [PATCH 0/2] sched_ext: Add a core event and update scx schedulers

[Changwoo Min]

Hi Tejun and Andrea,

On 25. 2. 8. 06:45, Andrea Righi wrote:
> On Fri, Feb 07, 2025 at 11:38:31AM -1000, Tejun Heo wrote:
>> I'm not sure. BPF schedulers should be able to avoid getting the default
>> slice. Hopefully, with the added visibility, this should be easier now. I'm
>> not sure how much overriding the default value in ops helps in terms of
>> control. It's a very half-way measure. Instead, how about we add tracepoint
>> to scx_add_event() so that folks who want to get backtrace of specific
>> events can get them easily so that it's easier to debug where these counts
>> are coming from? Let's just make it easier to avoid these events.
> 
> Yeah, that's a valid point, the implicit SCX_SLICE_DFL should be seen as a
> countermeasure for unhandled situations. Instead of fixing the
> countermeasure itself we should try to prevent it, if it proves to be
> problematic. And I like the idea of having a way to backtrace specific
> events.

I agree that adding a tracepoint to scx_add_event() and 
__scx_add_event() is a defenitely useful extension to further 
investigate what's going on. I will take a look.

Regards,
Changwoo Min