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

[Shrikanth Hegde <sshegde@linux.ibm.com>]

On 2/25/26 4:23 PM, Peter Zijlstra wrote:
> On Fri, Jan 09, 2026 at 04:53:04PM +0530, Shrikanth Hegde wrote:
> 
>>> --- a/kernel/sched/debug.c
>>> +++ b/kernel/sched/debug.c
>>> @@ -243,7 +243,7 @@ static ssize_t sched_dynamic_write(struc
>>>    static int sched_dynamic_show(struct seq_file *m, void *v)
>>>    {
>>> -	int i = IS_ENABLED(CONFIG_PREEMPT_RT) * 2;
>>> +	int i = (IS_ENABLED(CONFIG_PREEMPT_RT) || IS_ENABLED(CONFIG_ARCH_HAS_PREEMPT_LAZY)) * 2;
>>>    	int j;
>>>    	/* Count entries in NULL terminated preempt_modes */
>>
>> Maybe only change the default to LAZY, but keep other options possible via
>> dynamic update?
>>
>> - When the kernel changes to lazy being the default, the scheduling pattern
>> can change and it may affect the workloads. having ability to dynamically
>> change to none/voluntary could help one to figure out where
>> it is regressing. we could document cases where regression is expected.
> 
> I suppose we could do this. I just worry people will end up with 'echo
> volatile > /debug/sched/preempt' in their startup script, rather than
> trying to actually debug their issues.

Ack.

> 
> Anybody with enough knowledge to be useful, can edit this line on their
> own, rebuild the kernel and go forth.
> 
> Also, I've already heard people are interested in compile-time removing
> of cond_resched() infrastructure for ARCH_HAS_PREEMPT_LAZY, so this
> would be short lived indeed.
> 
>> - with preempt=full/lazy we will likely never see softlockups. How are we
>> going to find out longer kernel paths(some maybe design, some may be bugs)
>> apart from observing workload regression?
> 
> Given the utter cargo cult placement of cond_resched(); I don't think
> we've actually lost much here. You wouldn't have seen the softlockup
> thing anyway, because of cond_resched().
> 
> Anyway, you can always build on top of function graph tracing, create a
> flame graph of stuff and see just where all your runtime went. I'm sure
> there's tools that do this already. Perhaps if you're handy with the BPF
> stuff you can even create a 'watchdog' of sorts that will scream if any
> function takes longer than X us to run or whatever.
> 
> Oh, that reminds me, Steve, would it make sense to have
> task_struct::se.sum_exec_runtime as a trace-clock?
> 
>> Also, is softlockup code is of any use in preempt=full/lazy?
> 
> Softlockup has always seemed of dubious value to me -- then again, I've
> been running preempt=y kernels from about the day that became an option
> :-)
> 
> I think it still trips if you loose a wakeup or something.
> 

That's probably hungtask report right?
IIUC that would be independent of preemption model.