Re: [PATCH] sched/core: initialize resched_latency in sched_tick()

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

Hi.

> 
> The code has:
> 
> 	if (sched_feat(LATENCY_WARN))
> 		resched_latency = cpu_resched_latency(rq);
> 	calc_global_load_tick(rq);
> 	sched_core_tick(rq);
> 	scx_tick(rq);
> 
> 	rq_unlock(rq, &rf);
> 
> 	if (sched_feat(LATENCY_WARN) && resched_latency)
> 		resched_latency_warn(cpu, resched_latency);
> 
> 
> I guess if LATENCY_WARN gets enabled between the first check and the
> second, then the resched_latency could be uninitialized.
> 
> Heck, probably could even get rid of the second sched_feat(LATENCY_WARN),
> and make it simply:
> 
> 	if (resched_latency)
> 
> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> 
> -- Steve

Whats the relevance of resched_latency warnings in the age of preempt
kernels being the default for majority of the archs.

In case of full/lazy preemption, at the end of sched_tick itself we would call
schedule if need_resched is set provided it was preemptible.

It kind of makes sense for non preemptive kernels. But we have preemptoff and
preemptirqoff tracers which one could use. (although may need a kernel build)

What bugs is it catching these days?