Messages in this thread | | | Subject | Re: [PATCH v2 2/2] memory: samsung: exynos5422-dmc: Add module param to control IRQ mode | From | Lukasz Luba <> | Date | Fri, 17 Jul 2020 12:53:06 +0100 |
| |
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?
Cheers, Lukasz
| |