On Fri, 5 Jun 2020, Rafael J. Wysocki wrote: > > This sounds like it should be a known problem, but I couldn't find any > > mention of it in the documentation. > > Well, what would you expect to happen instead of what you see?
Not sure why you ask. Named workloads are pretty common for example on "build-bot" machines. If you don't work exclusively on the kernel you probably recognize that on, let's say, more "traditionally engineered" packages ./configure can take 10x more wall-clock time than subsequent 'make -j $(nproc)', and if schedutil makes the problem worse by consistently choosing the lowest possible frequency for the configure phase, that's a huge pitfall that's worth fixing or documenting. To answer your question, assuming schedutil is intended to become a good choice for a wide range of use-cases, I'd expect it to choose a high frequency, ideally the highest, and definitely not the lowest. I think I was pretty transparent about that in my initial mail. I understand there is no obvious fix and inventing one may prove difficult. Short term, better Kconfig help text to help people make a suitable choice for their workloads would be nice. I'd also like to point out that current Kconfig is confusingly worded where it says "If the utilization is frequency-invariant, ...". It can be interpreted as "the workload is producing the same utilization irrespective of frequency", but what it actually refers to is the implementation detail of how the "utilization" metric is interpreted. Does that sentence need to be in Kconfig help at all? Thanks. Alexander