Re: [PATCH] sched: Further restrict the preemption modes

[Steven Rostedt]

On Thu, 26 Feb 2026 11:00:14 +0530
Shrikanth Hegde <sshegde@xxxxxxxxxxxxx> wrote:

> On 2/26/26 6:18 AM, Steven Rostedt wrote:
> > On Wed, 25 Feb 2026 11:53:45 +0100
> > Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >   
> >> Oh, that reminds me, Steve, would it make sense to have
> >> task_struct::se.sum_exec_runtime as a trace-clock?  
> > 
> > That's unique per task right? As tracing is global it requires the
> > clock to be monotonic, and I'm guessing a single sched_switch will
> > break that.
> > 
> > Now if one wants to trace how long kernel paths are, I'm sure we could
> > trivially make a new tracer to do so.
> > 
> >    echo max_kernel_time > current_tracer  
> 
> That is good idea.

Yeah, I think something like this should be added now that LAZY will
prevent us from knowing where in the kernel is really going on for a long
time.

> 
> > 
> > or something like that, that could act like a latency tracer that
> > monitors how long any kernel thread runs without being preempted.
> > 
> > -- Steve  
> 
> With preempt=full/lazy a long running kernel task can get
> preempted if it is running in preemptible section. that's okay.
> 
> My intent was to have a tracer that can say, look this kernel task took this much time
> before it completed. For some task such as long page walk, we know it is okay since

Tracers can be set to only watch a single task. The function and function
graph tracers use set_ftrace_pid. I could extend that to other tracers.
Hmm, that may even be useful for the preemptirq tracer!

> it is expected to take time, but for some task such as reading watchdog shouldn't take
> time. But on large system's doing these global variable update itself may take a long time.
> Updating less often was a fix which had fixed that lockup IIRC. So how can we identify such
> opportunities. Hopefully I am making sense.

Not really. Can you explain in more detail, or specific examples of what
constitutes a path you want to trace and one that you do not?

-- Steve