On Wed, Nov 17, 2021 at 11:46 AM Lukasz Luba <lukasz.luba@xxxxxxx> wrote: > > Hi Rafael, > > On 11/16/21 7:05 PM, Rafael J. Wysocki wrote: > > On Mon, Nov 15, 2021 at 9:10 PM Thara Gopinath > > <thara.gopinath@xxxxxxxxxx> wrote: > >> > >> cpuinfo.max_freq can reflect boost frequency if enabled during boot. Since > >> we don't consider boost frequencies while calculating cpu capacities, use > >> policy->max to populate the freq_factor during boot up. > > > > I'm not sure about this. schedutil uses cpuinfo.max_freq as the max frequency. > > Agree it's tricky how we treat the boost frequencies and also combine > them with thermal pressure. > We probably would have consider these design bits: > 1. Should thermal pressure include boost frequency? Well, I guess so. Running at a boost frequency certainly increases thermal pressure. > 2. Should max capacity 1024 be a boost frequency so scheduler > would see it explicitly? That's what it is now if cpuinfo.max_freq is a boost frequency. > - if no, then schedutil could still request boost freq thanks to > map_util_perf() where we add 25% to the util and then > map_util_freq() would return a boost freq when util was > 1024 > > > I can see in schedutil only one place when cpuinfo.max_freq is used: > get_next_freq(). If the value stored in there is a boost, > then don't we get a higher freq value for the same util? Yes. we do, which basically is my point. The schedutil's response is proportional to cpuinfo.max_freq and that needs to be taken into account for the results to be consistent.
