Re: [RFC 0/3] mmc: Add dynamic frequency scaling
Quoting Ulf Hansson (2015-01-15 02:04:04) On 15 January 2015 at 10:20, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On czw, 2015-01-15 at 09:20 +0100, Ulf Hansson wrote: + Mike, Stephen (Clock maintainers) On 12 January 2015 at 10:23, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Hi, I would like to hear some comments about idea of scaling MMC clock frequency. The basic idea is to lower the clock when device is completely idle or not busy enough. We already have host drivers that implements runtime PM support. Typically that would mean the clock will be gated once the device becomes runtime PM suspended. Why should we decrease the frequency of an already gated clock? In case of idle state you're right that clkgate would be better. But what about finding a compromise between high performance (high frequency) and energy saving for different loads on MMC? I guess a compromise could be beneficial for some SOC and use cases. At least I remember, ST-Ericsson's UX500 SOC had such an out of tree hack to track MMC load. It is very important to model when resources are not needed, since this has some system-wide effects. There are two main use-cases I have in mind: 1) MMC clk is a leaf clock of some complex hierarchy (e.g. a PLL at the top of a clock sub-tree). If MMC is always locked at some fast rate (e.g. 48MHz instead of 24MHz or 12MHz) then that constraint prevents the rest of the hierarchy from transitioning to a lower frequency. Even if the MMC clock is aggressively gating, maximum system-level power savings may not be achieved since the rest of the clock sub-tree (starting at the PLL) will be stuck at a higher frequency than necessary. Thus, aggressive clock gating might give good power savings for the MMC case, but may be a blocker for other system components. 2) Wake-up latency constraints might make it impossible to clock gate, and thus the only power-saving option is to run at a lower frequency. This is not quite what is described above, but the point is that clock frequency scaling and clock gating are complementary power saving options, but we rely on the driver to model resource requirements accurately to get the best results. Regards, Mike The frequency scaling could help in that case. Anyway I should prepare some more benchmarks for such conditions. Seems reasonable and please do! Kind regards Uffe -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] mmc: Add dynamic frequency scaling
On 12 January 2015 at 10:23, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Hi, I would like to hear some comments about idea of scaling MMC clock frequency. The basic idea is to lower the clock when device is completely idle or not busy enough. The patchset adds MMC card as a devfreq device and uses simple_ondemand as governor. In idle this gave benefits (less energy consumed during idle): 1. Trats2 (Exynos4412): 2.6% 2. Rinato (Exynos3250): 1% but (especially on Rinato) it had impact on performance (probably because ondemand triggering a little to late). What is interesting manually changing the clock (without this patchset) gave slightly bigger benefits. Maybe the devfreq introduces noticeable overhead? Could it be because of the polling interval being too long thus it being too slow to ramp up? That's a problem with all polling devfreq drivers, it has been proposed before using pm_qos to to reduce the polling interval when some event indicates that the utilization may grow abruptly in the near future. I don't think pm_qos is the best mechanism for that, maybe something new needs to be devised. Regards, Tomeu Comments are welcomed. Maybe on other platforms this has bigger impact? Best regards, Krzysztof Krzysztof Kozlowski (3): mmc: Add dynamic frequency scaling ARM: dts: Specify MSHC realistic clocks and use frequency scaling ARM: dts: Use frequency scaling for MSHC Documentation/devicetree/bindings/mmc/mmc.txt | 2 + arch/arm/boot/dts/exynos3250-rinato.dts | 1 + arch/arm/boot/dts/exynos4412-trats2.dts | 4 +- drivers/mmc/card/block.c | 247 ++ drivers/mmc/core/Kconfig | 16 ++ drivers/mmc/core/core.h | 1 - drivers/mmc/core/host.c | 2 + include/linux/mmc/card.h | 8 + include/linux/mmc/host.h | 3 + 9 files changed, 282 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] mmc: Add dynamic frequency scaling
+ Mike, Stephen (Clock maintainers) On 12 January 2015 at 10:23, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Hi, I would like to hear some comments about idea of scaling MMC clock frequency. The basic idea is to lower the clock when device is completely idle or not busy enough. We already have host drivers that implements runtime PM support. Typically that would mean the clock will be gated once the device becomes runtime PM suspended. Why should we decrease the frequency of an already gated clock? I think this boils done to how DVFS transitions can be triggered from the clock drivers, right? Currently the clock framework supports this through clock rate change notifiers. Should we have clock notifiers for clk_prepare|unprepare() as well? I do remember that someone posted patches for that a while ago, but those were rejected. Mike, Stephen - comments? Kind regards Uffe The patchset adds MMC card as a devfreq device and uses simple_ondemand as governor. In idle this gave benefits (less energy consumed during idle): 1. Trats2 (Exynos4412): 2.6% 2. Rinato (Exynos3250): 1% but (especially on Rinato) it had impact on performance (probably because ondemand triggering a little to late). What is interesting manually changing the clock (without this patchset) gave slightly bigger benefits. Maybe the devfreq introduces noticeable overhead? Comments are welcomed. Maybe on other platforms this has bigger impact? Best regards, Krzysztof Krzysztof Kozlowski (3): mmc: Add dynamic frequency scaling ARM: dts: Specify MSHC realistic clocks and use frequency scaling ARM: dts: Use frequency scaling for MSHC Documentation/devicetree/bindings/mmc/mmc.txt | 2 + arch/arm/boot/dts/exynos3250-rinato.dts | 1 + arch/arm/boot/dts/exynos4412-trats2.dts | 4 +- drivers/mmc/card/block.c | 247 ++ drivers/mmc/core/Kconfig | 16 ++ drivers/mmc/core/core.h | 1 - drivers/mmc/core/host.c | 2 + include/linux/mmc/card.h | 8 + include/linux/mmc/host.h | 3 + 9 files changed, 282 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] mmc: Add dynamic frequency scaling
On czw, 2015-01-15 at 09:20 +0100, Ulf Hansson wrote: + Mike, Stephen (Clock maintainers) On 12 January 2015 at 10:23, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Hi, I would like to hear some comments about idea of scaling MMC clock frequency. The basic idea is to lower the clock when device is completely idle or not busy enough. We already have host drivers that implements runtime PM support. Typically that would mean the clock will be gated once the device becomes runtime PM suspended. Why should we decrease the frequency of an already gated clock? In case of idle state you're right that clkgate would be better. But what about finding a compromise between high performance (high frequency) and energy saving for different loads on MMC? The frequency scaling could help in that case. Anyway I should prepare some more benchmarks for such conditions. Best regards, Krzysztof I think this boils done to how DVFS transitions can be triggered from the clock drivers, right? Currently the clock framework supports this through clock rate change notifiers. Should we have clock notifiers for clk_prepare|unprepare() as well? I do remember that someone posted patches for that a while ago, but those were rejected. Mike, Stephen - comments? Kind regards Uffe The patchset adds MMC card as a devfreq device and uses simple_ondemand as governor. In idle this gave benefits (less energy consumed during idle): 1. Trats2 (Exynos4412): 2.6% 2. Rinato (Exynos3250): 1% but (especially on Rinato) it had impact on performance (probably because ondemand triggering a little to late). What is interesting manually changing the clock (without this patchset) gave slightly bigger benefits. Maybe the devfreq introduces noticeable overhead? Comments are welcomed. Maybe on other platforms this has bigger impact? Best regards, Krzysztof Krzysztof Kozlowski (3): mmc: Add dynamic frequency scaling ARM: dts: Specify MSHC realistic clocks and use frequency scaling ARM: dts: Use frequency scaling for MSHC Documentation/devicetree/bindings/mmc/mmc.txt | 2 + arch/arm/boot/dts/exynos3250-rinato.dts | 1 + arch/arm/boot/dts/exynos4412-trats2.dts | 4 +- drivers/mmc/card/block.c | 247 ++ drivers/mmc/core/Kconfig | 16 ++ drivers/mmc/core/core.h | 1 - drivers/mmc/core/host.c | 2 + include/linux/mmc/card.h | 8 + include/linux/mmc/host.h | 3 + 9 files changed, 282 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] mmc: Add dynamic frequency scaling
On 15 January 2015 at 10:20, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On czw, 2015-01-15 at 09:20 +0100, Ulf Hansson wrote: + Mike, Stephen (Clock maintainers) On 12 January 2015 at 10:23, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Hi, I would like to hear some comments about idea of scaling MMC clock frequency. The basic idea is to lower the clock when device is completely idle or not busy enough. We already have host drivers that implements runtime PM support. Typically that would mean the clock will be gated once the device becomes runtime PM suspended. Why should we decrease the frequency of an already gated clock? In case of idle state you're right that clkgate would be better. But what about finding a compromise between high performance (high frequency) and energy saving for different loads on MMC? I guess a compromise could be beneficial for some SOC and use cases. At least I remember, ST-Ericsson's UX500 SOC had such an out of tree hack to track MMC load. The frequency scaling could help in that case. Anyway I should prepare some more benchmarks for such conditions. Seems reasonable and please do! Kind regards Uffe -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/3] mmc: Add dynamic frequency scaling
Hi, I would like to hear some comments about idea of scaling MMC clock frequency. The basic idea is to lower the clock when device is completely idle or not busy enough. The patchset adds MMC card as a devfreq device and uses simple_ondemand as governor. In idle this gave benefits (less energy consumed during idle): 1. Trats2 (Exynos4412): 2.6% 2. Rinato (Exynos3250): 1% but (especially on Rinato) it had impact on performance (probably because ondemand triggering a little to late). What is interesting manually changing the clock (without this patchset) gave slightly bigger benefits. Maybe the devfreq introduces noticeable overhead? Comments are welcomed. Maybe on other platforms this has bigger impact? Best regards, Krzysztof Krzysztof Kozlowski (3): mmc: Add dynamic frequency scaling ARM: dts: Specify MSHC realistic clocks and use frequency scaling ARM: dts: Use frequency scaling for MSHC Documentation/devicetree/bindings/mmc/mmc.txt | 2 + arch/arm/boot/dts/exynos3250-rinato.dts | 1 + arch/arm/boot/dts/exynos4412-trats2.dts | 4 +- drivers/mmc/card/block.c | 247 ++ drivers/mmc/core/Kconfig | 16 ++ drivers/mmc/core/core.h | 1 - drivers/mmc/core/host.c | 2 + include/linux/mmc/card.h | 8 + include/linux/mmc/host.h | 3 + 9 files changed, 282 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
