From: Lukasz Luba <lukasz.luba@arm.com>
To: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: linux-samsung-soc@vger.kernel.org, s.nawrocki@samsung.com,
linux-pm@vger.kernel.org, k.konieczny@samsung.com,
linux-kernel@vger.kernel.org, krzk@kernel.org,
cw00.choi@samsung.com, kyungmin.park@samsung.com,
willy.mh.wolff.ml@gmail.com, myungjoo.ham@samsung.com,
chanwoo@kernel.org, kgene@kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/2] memory: samsung: exynos5422-dmc: Add module param to control IRQ mode
Date: Fri, 17 Jul 2020 12:53:06 +0100 [thread overview]
Message-ID: <baadfe1a-89b6-9fd5-9ea8-e39b458af1aa@arm.com> (raw)
In-Reply-To: <3154b8d2-1fa8-c69d-8a9d-05832e12fdd1@arm.com>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-07-17 11:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200710191144epcas1p30f82bf6371f7f09a4e1ea1262234f392@epcas1p3.samsung.com>
2020-07-10 19:11 ` [PATCH v2 0/2] Exynos5422 DMC: adjust to new devfreq monitoring mechanism Lukasz Luba
2020-07-10 19:11 ` [PATCH v2 1/2] memory: samsung: exynos5422-dmc: Adjust polling interval and uptreshold Lukasz Luba
2020-07-20 14:46 ` Krzysztof Kozlowski
2020-07-27 8:20 ` Lukasz Luba
2020-07-10 19:11 ` [PATCH v2 2/2] memory: samsung: exynos5422-dmc: Add module param to control IRQ mode Lukasz Luba
2020-07-14 7:42 ` Bartlomiej Zolnierkiewicz
2020-07-14 9:01 ` Lukasz Luba
2020-07-14 9:32 ` Willy Wolff
2020-07-14 9:50 ` Lukasz Luba
2020-07-17 11:53 ` Lukasz Luba [this message]
2020-07-17 12:31 ` Bartlomiej Zolnierkiewicz
2020-07-20 14:46 ` Krzysztof Kozlowski
2020-08-03 15:30 ` Marek Szyprowski
2020-08-03 15:35 ` Marek Szyprowski
2020-08-04 8:06 ` Lukasz Luba
2020-07-24 1:40 ` [PATCH v2 0/2] Exynos5422 DMC: adjust to new devfreq monitoring mechanism Chanwoo Choi
2020-07-27 8:21 ` Lukasz Luba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=baadfe1a-89b6-9fd5-9ea8-e39b458af1aa@arm.com \
--to=lukasz.luba@arm.com \
--cc=b.zolnierkie@samsung.com \
--cc=chanwoo@kernel.org \
--cc=cw00.choi@samsung.com \
--cc=k.konieczny@samsung.com \
--cc=kgene@kernel.org \
--cc=krzk@kernel.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=myungjoo.ham@samsung.com \
--cc=s.nawrocki@samsung.com \
--cc=willy.mh.wolff.ml@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).