> A user who starts a browser on a mobile device wants it to respond quickly, but PELT will take a few 32ms measurement cycles to fully understand the load that the browser is placing on the system.

Isn't the obvious solution to just give a boost to a process that receives user input and/or that is launched by a process receiving user input? (I believe Windows does this?) Why isn't Linux doing this?

Android does exactly that. (Called foreground processes.) It breaks things that require steady throughput and low latency, like media handling. Everywhere where you need a wake-up estimate and are using a dumb controller to get runtime, you get immense noise.

It is also highly unnecessary. If you have preemptible kernel, standard task start handling puts new tasks on top of their parents tree of tasks to be scheduled. (Tunable in sysfs.) If there is no restart, boost shouldn't be necessary on a preemptible kernel anyway, especially rt enabled ones, as lock holders on input will get woken up.

About the only place where it is useful is in boosting cpu clocks. This is also where it breaks timings the most.

> About the only place where it is useful is in boosting cpu clocks.

This is true, but it is still absolutely critical for making Android usable. If you disable boosting i.e. allow tasks to take several frame refresh periods to accumulate load and bring the CPU freq up, you get a really painful UX.

Not really. 90+% of the time touch screen process gets the cpu boosted before you're even done touching the screen with modern ondemand coufreq. (I mean like 4.12 or newer) Try it out one of these days, but don't forget you can tweak sampling periods.

Conservative cpufreq uses load. Ondemand only sort of does.

The problem still remains getting predictable tick timings working well. (not missing deadlines)

Linux doesn't include the entire windowing stack in the kernel so it cannot apply that kind of heuristic. There is a user space solution though - ulatencyd.

As far as I know Linux uses a different heuristic that achieves similar results.

A process that sometimes, but not all the time, uses a lot of cpu time is considered interactive and prioritized accordingly.

How does one install this new way of measuring CPU utilisation?

You have to enable the SCHED_UTILEST flag when compiling the kernel. Most end-users don't compile their own kernels, as doing so requires a very large and time-consuming amount of configuration, but you can if you want (might want to start with your distribution's configuration as a base).

Do note that this does not work on multiple CPU's (e.g. 2 sockets) it does however work on multiple cores. ( 1 physical CPU with multiple cores )