On 7/17/20 1:53 PM, Lukasz Luba wrote: > > > On 7/14/20 10:01 AM, Lukasz Luba wrote: >> Hi Bartek, >> >> On 7/14/20 8:42 AM, Bartlomiej Zolnierkiewicz wrote: >>> >>> Hi, >>> >>> On 7/10/20 9:11 PM, Lukasz Luba wrote: >>>> The driver can operate in two modes relaying on devfreq monitoring >>>> mechanism which periodically checks the device status or it can use >>>> interrupts when they are provided by loaded Device Tree. The newly >>>> introduced module parameter can be used to choose between devfreq >>>> monitoring and internal interrupts without modifying the Device Tree. >>>> It also sets devfreq monitoring as default when the parameter is not set >>>> (also the case for default when the driver is not built as a module). >>> >>> Could you please explain why should we leave the IRQ mode >>> support in the dmc driver? >> >> I am still experimenting with the IRQ mode in DMC, but have limited time >> for it and no TRM. >> The IRQ mode in memory controller or bus controller has one major >> advantage: is more interactive. In polling we have fixed period, i.e. >> 100ms - that's a lot when we have a sudden, latency sensitive workload. >> There might be no check of the device load for i.e. 99ms, but the tasks >> with such workload started running. That's a long period of a few frames >> which are likely to be junked. Should we adjust polling interval to i.e. >> 10ms, I don't think so. There is no easy way to address all of the >> scenarios. >> >>> >>> What are the advantages over the polling mode? >> >> As described above: more reactive to sudden workload, which might be >> latency sensitive and cause junk frames. >> Drawback: not best in benchmarks which are randomly jumping >> over the data set, causing low traffic on memory. >> It could be mitigated as Sylwester described with not only one type >> of interrupt, but another, which could 'observe' also other information >> type in the counters and fire. >> >>> >>> In what scenarios it should be used? >> >> System like Android with GUI, when there is this sudden workload >> quite often. >> >> I think the interconnect could help here and would adjust the DMC >> freq upfront. Although I don't know if interconnect on Exynos5422 is in >> your scope in near future. Of course the interconnect will not cover >> all scenarios either. >> >> >>> >>> [ If this is only for documentation purposes then it should be >>> removed as it would stay in (easily accessible) git history >>> anyway.. ] >> >> The current interrupt mode is definitely not perfect and switching >> to devfreq monitoring mode has more sense. On the other hand, it >> still has potential, until there is no interconnect for this SoC. >> I will continue experimenting with irq mode, so I would like to >> still have the code in the driver. >> >> Regards, >> Lukasz >> >>> >>> Best regards, >>> -- >>> Bartlomiej Zolnierkiewicz >>> Samsung R&D Institute Poland >>> Samsung Electronics >>> > > Bartek, do you have some objections to the patches or you think > they can be taken via devfreq-next? No objections from me, thank you for the IRQ mode explanation. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
