On Fri, Jun 05, 2020 at 06:51:12PM +0200, Rafael J. Wysocki wrote: > On 6/4/2020 11:29 PM, Alexander Monakov wrote:
> > this is a question/bugreport about behavior of schedutil on serial workloads > > such as rsync, or './configure', or 'make install'. These workloads are > > such that there's no single task that takes a substantial portion of CPU > > time, but at any moment there's at least one runnable task, and overall > > the workload is compute-bound. To run the workload efficiently, cpufreq > > governor should select a high frequency. > > > > Assume the system is idle except for the workload in question. > > > > Sadly, schedutil will select the lowest frequency, unless the workload is > > confined to one core with taskset (in which case it will select the > > highest frequency, correctly though somewhat paradoxically). > > That's because the CPU utilization generated by the workload on all CPUs is > small. > > Confining it to one CPU causes the utilization of this one to grow and so > schedutil selects a higher frequency for it. My initial question was why doesn't io-boosting fix this up, but a quick look at our pipe code shows me that it doesn't seem to use io_schedule(). That is currently our only means to express 'someone is waiting on us' to which we then say 'lets hurry up a bit'. Because, as you've found, if the tasks do not queue up, there is nothing to push the frequency up.