On Tue, Jun 28, 2022 at 5:47 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > On 6/27/22 02:36, Linus Walleij wrote: > > The right way to solve this is to make the Linux kernel contain the > > necessary heuristics to identify which tasks and thus cores need this > > to improve efficiency and then apply it automatically. > > I agree in theory. But, I also want a pony in theory. > > Any suggestions for how to do this in the real world? Well if the knobs are exposed to userspace, how do people using these knobs know when to turn them? A profiler? perf? All that data is available to the kernel too. The memory access pattern statistics from mm/damon was what I suggested as a starting point. We have pretty elaborate heuristics in the kernel to identify the behaviour of processes, one example is the BFQ block scheduler which determines I/O priority weights of processed based on how interactive they are. If we can determine things like that I am pretty sure we can determine how computing intense a task is for example, by using memory access statistics and scheduler information: if the process is constantly READY to run over a few context switches and PC also stays in a certain rage of memory like two adjacent pages then it is probably running a hard kernel, if that is what we need to know here. It doesn't seem too far-fetched? We have the performance counters as well. That should be possible to utilize to get even more precise heuristics? Maybe that is what userspace is using to determine this already. I'm not saying there has to be a simple solution, but maybe there is something like a really complicated solution? We have academic researchers that like to look at things like this. > Otherwise, I'm inclined to say that this series incrementally makes > things better in the real world by at least moving folks away from wrmsr(1). I don't know if yet another ABI that needs to be maintained helps the situation much, it's just a contract that we will have to maintain for no gain. However if userspace is messing with that register behind our back and we know better, we can just overwrite it with the policy we determine is better in the kernel. Yours, Linus Walleij
