[PATCH 0/1][N/U] Enable lowlatency settings in the generic kernel

[Andrea Righi]

On Fri, Jan 26, 2024 at 07:25:48PM +0000, Dimitri John Ledkov wrote:
...
> > With all of that in place we can provide a kernel that has the
> > flexibility to be more responsive, more performant and more power
> > efficient (therefore more "generic"), simply by tuning run-time and
> > boot-time options.
> >
> > Moreover, once these changes are applied we will be able to deprecate
> > the lowlatency kernel, saving engineering time and also reducing power
> > consumption (required to build the kernel and do all the testing).
> >
> > Optionally, we can also provide the optimal "lowlatency" settings as a
> > user-space package that would set the proper options in the kernel boot
> > command line (GRUB, or similar).
> 
> Also it is no longer clear what the target workload is. Because for
> many use cases we have been receiving requests for lowlatency kernels
> in the server space, and in the public cloud space. And our cloud
> kernels are used a lot for cloud desktop, cloud gaming, cloud
> streaming solutions. As in they are very much interactive.

Absolutely, I think CONFIG_HZ=250 is actually penalizing servers and
clouds. It's more like a setting for HPC. And even HPC nowdays relies a
lot on fast interconnections / MPI more than raw CPU power, so, even in
this scenario resonsiveness is important.

> 
> I do wish HZ was not a build-time constant macro, but a runtime
> tunable - or like at least boot-time set once variable. As that indeed
> would let us half the builds, and still allow cpu bound workloads
> succeed.

Yeah, unfortunately the overhead of having HZ as a variable (or even a
boot-time constant) requires to completely rewrite all the timing
macros, and the overhead would be probably much bigger than the benefit
of switching the different HZ live.

-Andrea