Applied to drm-misc-next. Regards, Qiang On Thu, Feb 4, 2021 at 10:24 PM Lukasz Luba <lukasz.luba@xxxxxxx> wrote: > > > > On 2/4/21 1:39 PM, Robin Murphy wrote: > > On 2021-02-03 02:01, Qiang Yu wrote: > >> On Tue, Feb 2, 2021 at 10:02 PM Lukasz Luba <lukasz.luba@xxxxxxx> wrote: > >>> > >>> > >>> > >>> On 2/2/21 1:01 AM, Qiang Yu wrote: > >>>> Hi Lukasz, > >>>> > >>>> Thanks for the explanation. So the deferred timer option makes a > >>>> mistake that > >>>> when GPU goes from idle to busy for only one poll periodic, in this > >>>> case 50ms, right? > >>> > >>> Not exactly. Driver sets the polling interval to 50ms (in this case) > >>> because it needs ~3-frame average load (in 60fps). I have discovered the > >>> issue quite recently that on systems with 2 CPUs or more, the devfreq > >>> core is not monitoring the devices even for seconds. Therefore, we might > >>> end up with quite big amount of work that GPU is doing, but we don't > >>> know about it. Devfreq core didn't check <- timer didn't fired. Then > >>> suddenly that CPU, which had the deferred timer registered last time, > >>> is waking up and timer triggers to check our device. We get the stats, > >>> but they might be showing load from 1sec not 50ms. We feed them into > >>> governor. Governor sees the new load, but was tested and configured for > >>> 50ms, so it might try to rise the frequency to max. The GPU work might > >>> be already lower and there is no need for such freq. Then the CPU goes > >>> idle again, so no devfreq core check for next e.g. 1sec, but the > >>> frequency stays at max OPP and we burn power. > >>> > >>> So, it's completely unreliable. We might stuck at min frequency and > >>> suffer the frame drops, or sometimes stuck to max freq and burn more > >>> power when there is no such need. > >>> > >>> Similar for thermal governor, which is confused by this old stats and > >>> long period stats, longer than 50ms. > >>> > >>> Stats from last e.g. ~1sec tells you nothing about real recent GPU > >>> workload. > >> Oh, right, I missed this case. > >> > >>> > >>>> But delayed timer will wakeup CPU every 50ms even when system is > >>>> idle, will this > >>>> cause more power consumption for the case like phone suspend? > >>> > >>> No, in case of phone suspend it won't increase the power consumption. > >>> The device won't be woken up, it will stay in suspend. > >> I mean the CPU is waked up frequently by timer when phone suspend, > >> not the whole device (like the display). > >> > >> Seems it's better to have deferred timer when device is suspended for > >> power saving, > >> and delayed timer when device in working state. User knows this and > >> can use sysfs > >> to change it. > > > > Doesn't devfreq_suspend_device() already cancel any timer work either > > way in that case? > > Correct, the governor should pause the monitoring mechanism (and timer). > > Regards, > Lukasz _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
