scheduler: updated sched knobs for kernels 6.6+

[yarda]

sched_wakeup_granularity_ns - removed
sched_min_granularity_ns - now sched_base_slice_ns, same units and scale
sched_latency_ns - removed

[zacikpa]

The change looks functionally OK and works fine also on the newest kernels.

I wonder whether it's necessary to differentiate the case when a knob once existed, but does not exist now (reporting only a debug message). Wouldn't it be cleaner to unify the behavior to always check for the existence of the knobs before accessing them and report a warning if they don't exist?

[yarda]

@zacikpa thanks for the review.

I wonder whether it's necessary to differentiate the case when a knob once existed, but does not exist now (reporting only a debug message). Wouldn't it be cleaner to unify the behavior to always check for the existence of the knobs before accessing them and report a warning if they don't exist?

If I understand your comment correctly this would output warnings on 6.6 kernels, i.e. on RHELs newer than RHEL-9 until we drop the sched tunings from the stock profiles. And if we remove the sched tunings from the stock profiles than we will have regression on older kernels. I think the compatibility layer should work transparently. I.e. it should try the pre 5.13 knobs, then the 5.13 knobs and finally the 6.6 knobs. If the knob is known as removed without replacement then I think it's OK to do nothing.

I am open to discussion.

[zacikpa]

Your points are right.

I wanted to avoid inconsistencies where you could, e.g., be running a kernel between 5.13 and 6.6 and (for some unknown reason) be missing two knobs: say sched_latency_ns and sched_tunable_scaling. For the first one, TuneD would only report a debug message (assuming it's on a 6.6+ kernel), and for the second one, it would correctly report an error.

But I guess such a scenario is quite unlikely.