Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
[Adding Linaro lists in cc as there are few people here working on power/thermal stuff.] On 24 March 2014 15:30, Lukasz Majewski wrote: >> On 4 March 2014 15:57, Lukasz Majewski wrote: > I think, that "LAB" name is with us for some time, so it would be a > pity to discard it. It doesn't matter with Mainline how you do naming initially for your code :) We need to pick the right name now, and the decision should be made now (after discussions obviously) :) >> What about making it as simple as: >> - changing the ondemand governor only instead of adding a new governor > > My goal is to not touch the ondemand code. It has matured, so I would > like to leave it as it is. Because the boost feature is already part of CPUFreq core, I think its better if we enhance current governors to use it. So, I would like to make this part of existing governors. Not only ondemand but maybe conservative as well.. Also, I feel we maynot necessarily move this piece of code into cpufreq. All you are doing is thermal management here :) If we are sure we will not burn out our SoC (When many cores are idle), run at max freq (if there is enough load of course :)).. And if there are chances that we might burn our chip (when very few cores are idle), don't run on boost frequencies.. This is actually a 'cooling' device :) Think of it this way: CPUFreq will provide a range of frequency which SoC's can use. And then based on some conditions we may or may not want to run on these frequencies. @Zhang/Eduardo: Can we have your inputs here as well ? This may look hard but we need to design things in the best possible way for managing things better in future. Lets see what others have to say on this. -- 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/
Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
Hi Viresh, > On 4 March 2014 15:57, Lukasz Majewski wrote: > > Despite this patch set is working and applicable on top of 3.14-rc5, > > please regard it solely as a pure RFC. > > Okay, I am trying to do a review here and because you have mentioned > how different it is from the earlier versions, I am trying with a > fresh mind. i.e. with zero memories of earlier discussions :) > > LAB was: Legacy Application Boost ?? Yes, correct. > > Probably mention that in your new threads as well, so that new readers > know the details. Also, like other governors, just name it "boost" > governor. I think, that "LAB" name is with us for some time, so it would be a pity to discard it. > > > This patch provides support for LAB governor build on top of > > ondemand. Previous version of LAB can be found here: > > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > > > LAB short reminder: > > > > LAB uses information about how many cores are in "idle" state (the > > core idleness is represented as the value between 0 and 100) and > > the overall load of the system (from 0 to 100) to decide about > > frequency to be set. It is extremely useful with SoCs like > > Exynos4412, which can set only one frequency for all cores. > > Probably a description of how exactly these two values come into play > would have been more interesting here for all. Always think of new > followers of your patchset and so add all interesting things about it > when you resend it. > > If I remember well the logic was more or less like this: > - More idle cores means run few running cores at high frequency > - Less idle cores means don't run them at very high frequencies > > Right? This is correct. Also, the underlying SoC - Exynos4412 has 4 cores with option to set frequency only on all of them. > > What about making it as simple as: > - changing the ondemand governor only instead of adding a new governor My goal is to not touch the ondemand code. It has matured, so I would like to leave it as it is. > - Keeping the bahavior as is for all platforms not publishing boost > frequencies This is also done - you get the LAB configuration specified in the DT for the particular platform/board. > - If more cores are idle, enable switching to boost frequencies and > take them into consideration all the time. I'm not sure if I have understood you, but something like that is also performed in the code. > - If less cores are idle, disable boost frequencies.. As written above. > > Lets discuss this first and then I will get into the very details of > your implementation. Discussion about above functionalities requires consulting the implementation to be sure that our opinions are the same. -- Best regards, Lukasz Majewski Samsung R Institute Poland (SRPOL) | Linux Platform Group -- 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/
Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
On 4 March 2014 15:57, Lukasz Majewski wrote: > Despite this patch set is working and applicable on top of 3.14-rc5, > please regard it solely as a pure RFC. Okay, I am trying to do a review here and because you have mentioned how different it is from the earlier versions, I am trying with a fresh mind. i.e. with zero memories of earlier discussions :) LAB was: Legacy Application Boost ?? Probably mention that in your new threads as well, so that new readers know the details. Also, like other governors, just name it "boost" governor. > This patch provides support for LAB governor build on top of ondemand. > Previous version of LAB can be found here: > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > LAB short reminder: > > LAB uses information about how many cores are in "idle" state (the core > idleness is represented as the value between 0 and 100) and the overall > load of the system (from 0 to 100) to decide about frequency to be set. > It is extremely useful with SoCs like Exynos4412, which can set only one > frequency for all cores. Probably a description of how exactly these two values come into play would have been more interesting here for all. Always think of new followers of your patchset and so add all interesting things about it when you resend it. If I remember well the logic was more or less like this: - More idle cores means run few running cores at high frequency - Less idle cores means don't run them at very high frequencies Right? What about making it as simple as: - changing the ondemand governor only instead of adding a new governor - Keeping the bahavior as is for all platforms not publishing boost frequencies - If more cores are idle, enable switching to boost frequencies and take them into consideration all the time. - If less cores are idle, disable boost frequencies.. Lets discuss this first and then I will get into the very details of your implementation. -- 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/
Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
On 24 March 2014 12:17, Lukasz Majewski wrote: > Viresh, will you find time for reviewing this RFC in a near future? Yes. I have been trying hard last week but couldn't find some time for it. Will try this week for sure.. Sorry to keep you waiting :( @Rafael: Please see if you can also give them a look.. -- 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/
Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
Hi Viresh, > Hi Viresh, > > > On 17 March 2014 21:08, Lukasz Majewski > > wrote: > > >> Despite this patch set is working and applicable on top of > > >> 3.14-rc5, please regard it solely as a pure RFC. > > >> > > >> This patch provides support for LAB governor build on top of > > >> ondemand. Previous version of LAB can be found here: > > >> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > >> > > >> LAB short reminder: > > >> > > >> LAB uses information about how many cores are in "idle" state > > >> (the core idleness is represented as the value between 0 and > > >> 100) and the overall load of the system (from 0 to 100) to > > >> decide about frequency to be set. It is extremely useful with > > >> SoCs like Exynos4412, which can set only one frequency for all > > >> cores. > > >> > > >> Important design decisions: > > >> > > >> - Reuse well established ondemand governor's internal code. To do > > >> this I had to expose some previously static internal ondemand > > >> code. This allowed smaller LAB code when compared to previous > > >> version. > > >> > > >> - LAB works on top of ondemand, which means that one via device > > >> tree attributes can specify if and when e.g. BOOST shall be > > >> enabled or if any particular frequency shall be imposed. For > > >> situation NOT important from the power consumption reduction > > >> viewpoint the ondemand is used to set proper frequency. > > >> > > >> - It is only possible to either compile in or not the LAB into > > >> the kernel. There is no "M" option for Kconfig. It is done on > > >> purpose, since ondemand itself can be also compiled as a module > > >> and then it would be possible to remove ondemand when LAB is > > >> working on top of it. > > >> > > >> - The LAB operation is specified (and thereof extendable) via > > >> device tree lab-ctrl-freq attribute defined at /cpus/cpu0. > > >> > > >> > > >> Problems: > > >> - How the governor will work for big.LITTLE systems (especially > > >> Global Task Scheduling). > > >> - Will there be agreement to expose internal ondemand code to be > > >> reused for more specialized governors. > > >> > > >> Test HW: > > >> Exynos4412 - Trats2 board. > > >> Above patches were posted on top of Linux 3.14-rc5 > > >> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6) > > >> > > > > > > Any comments about those patches? > > > > Sorry for being late on reviewing these.. > > > > I tried to go through the patches but didn't looked at the minutest > > of the details. Its been a long time when you first sent this > > patchset. And the memories have corrupted by now :) .. > > Unfortunately memory is volatile ... since LAB governor is a follow up > of BOOST, which review and inclusion took considerable time, some > details could be forgotten. > > > > > To get context back, can we discuss again the fundamentals behind > > this new governor you are proposing. And then we can discuss about > > it again, its pros/cons, etc.. > > Please consider following links: > > The original implementation - threads: > http://thread.gmane.org/gmane.linux.power-management.general/32523/match=lab > http://thread.gmane.org/gmane.linux.kernel/1484746/match=lab > > > LAB justification data: > http://article.gmane.org/gmane.linux.kernel/1472381 > > > > People are reluctant in getting another governor in and want to give > > existing governors a try if possible. > > As I've stated in the covering letter, this code is an extension of > Ondemand. > > This is totally different from what have been posted previously (v1, > v2). > The first LAB proposal was written with some parts copied from > Ondemand. It was a separate, standalone governor. > > > The approach proposed in those patches is very different. It simply > reuses Ondemand code as much as possible (timers, default attributes > exported to sysfs, etc.). > > On top of the Ondemand we have the LAB, which thereof is its optional > extension. The existing code is reused and can be easily extracted as > a common code. > > > > > So, please explain the basics behind your governor again and then > > we can put our arguments again.. > > > > I hope that provided overview is sufficient. More in depth > information can be found in posted patches or provided LKML archives. > Viresh, will you find time for reviewing this RFC in a near future? > > -- > > viresh > -- Best regards, Lukasz Majewski Samsung R Institute Poland (SRPOL) | Linux Platform Group -- 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/
Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
Hi Viresh, Hi Viresh, On 17 March 2014 21:08, Lukasz Majewski l.majew...@samsung.com wrote: Despite this patch set is working and applicable on top of 3.14-rc5, please regard it solely as a pure RFC. This patch provides support for LAB governor build on top of ondemand. Previous version of LAB can be found here: http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq LAB short reminder: LAB uses information about how many cores are in idle state (the core idleness is represented as the value between 0 and 100) and the overall load of the system (from 0 to 100) to decide about frequency to be set. It is extremely useful with SoCs like Exynos4412, which can set only one frequency for all cores. Important design decisions: - Reuse well established ondemand governor's internal code. To do this I had to expose some previously static internal ondemand code. This allowed smaller LAB code when compared to previous version. - LAB works on top of ondemand, which means that one via device tree attributes can specify if and when e.g. BOOST shall be enabled or if any particular frequency shall be imposed. For situation NOT important from the power consumption reduction viewpoint the ondemand is used to set proper frequency. - It is only possible to either compile in or not the LAB into the kernel. There is no M option for Kconfig. It is done on purpose, since ondemand itself can be also compiled as a module and then it would be possible to remove ondemand when LAB is working on top of it. - The LAB operation is specified (and thereof extendable) via device tree lab-ctrl-freq attribute defined at /cpus/cpu0. Problems: - How the governor will work for big.LITTLE systems (especially Global Task Scheduling). - Will there be agreement to expose internal ondemand code to be reused for more specialized governors. Test HW: Exynos4412 - Trats2 board. Above patches were posted on top of Linux 3.14-rc5 (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6) Any comments about those patches? Sorry for being late on reviewing these.. I tried to go through the patches but didn't looked at the minutest of the details. Its been a long time when you first sent this patchset. And the memories have corrupted by now :) .. Unfortunately memory is volatile ... since LAB governor is a follow up of BOOST, which review and inclusion took considerable time, some details could be forgotten. To get context back, can we discuss again the fundamentals behind this new governor you are proposing. And then we can discuss about it again, its pros/cons, etc.. Please consider following links: The original implementation - threads: http://thread.gmane.org/gmane.linux.power-management.general/32523/match=lab http://thread.gmane.org/gmane.linux.kernel/1484746/match=lab LAB justification data: http://article.gmane.org/gmane.linux.kernel/1472381 People are reluctant in getting another governor in and want to give existing governors a try if possible. As I've stated in the covering letter, this code is an extension of Ondemand. This is totally different from what have been posted previously (v1, v2). The first LAB proposal was written with some parts copied from Ondemand. It was a separate, standalone governor. The approach proposed in those patches is very different. It simply reuses Ondemand code as much as possible (timers, default attributes exported to sysfs, etc.). On top of the Ondemand we have the LAB, which thereof is its optional extension. The existing code is reused and can be easily extracted as a common code. So, please explain the basics behind your governor again and then we can put our arguments again.. I hope that provided overview is sufficient. More in depth information can be found in posted patches or provided LKML archives. Viresh, will you find time for reviewing this RFC in a near future? -- viresh -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- 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/
Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
On 24 March 2014 12:17, Lukasz Majewski l.majew...@samsung.com wrote: Viresh, will you find time for reviewing this RFC in a near future? Yes. I have been trying hard last week but couldn't find some time for it. Will try this week for sure.. Sorry to keep you waiting :( @Rafael: Please see if you can also give them a look.. -- 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/
Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
On 4 March 2014 15:57, Lukasz Majewski l.majew...@samsung.com wrote: Despite this patch set is working and applicable on top of 3.14-rc5, please regard it solely as a pure RFC. Okay, I am trying to do a review here and because you have mentioned how different it is from the earlier versions, I am trying with a fresh mind. i.e. with zero memories of earlier discussions :) LAB was: Legacy Application Boost ?? Probably mention that in your new threads as well, so that new readers know the details. Also, like other governors, just name it boost governor. This patch provides support for LAB governor build on top of ondemand. Previous version of LAB can be found here: http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq LAB short reminder: LAB uses information about how many cores are in idle state (the core idleness is represented as the value between 0 and 100) and the overall load of the system (from 0 to 100) to decide about frequency to be set. It is extremely useful with SoCs like Exynos4412, which can set only one frequency for all cores. Probably a description of how exactly these two values come into play would have been more interesting here for all. Always think of new followers of your patchset and so add all interesting things about it when you resend it. If I remember well the logic was more or less like this: - More idle cores means run few running cores at high frequency - Less idle cores means don't run them at very high frequencies Right? What about making it as simple as: - changing the ondemand governor only instead of adding a new governor - Keeping the bahavior as is for all platforms not publishing boost frequencies - If more cores are idle, enable switching to boost frequencies and take them into consideration all the time. - If less cores are idle, disable boost frequencies.. Lets discuss this first and then I will get into the very details of your implementation. -- 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/
Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
Hi Viresh, On 4 March 2014 15:57, Lukasz Majewski l.majew...@samsung.com wrote: Despite this patch set is working and applicable on top of 3.14-rc5, please regard it solely as a pure RFC. Okay, I am trying to do a review here and because you have mentioned how different it is from the earlier versions, I am trying with a fresh mind. i.e. with zero memories of earlier discussions :) LAB was: Legacy Application Boost ?? Yes, correct. Probably mention that in your new threads as well, so that new readers know the details. Also, like other governors, just name it boost governor. I think, that LAB name is with us for some time, so it would be a pity to discard it. This patch provides support for LAB governor build on top of ondemand. Previous version of LAB can be found here: http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq LAB short reminder: LAB uses information about how many cores are in idle state (the core idleness is represented as the value between 0 and 100) and the overall load of the system (from 0 to 100) to decide about frequency to be set. It is extremely useful with SoCs like Exynos4412, which can set only one frequency for all cores. Probably a description of how exactly these two values come into play would have been more interesting here for all. Always think of new followers of your patchset and so add all interesting things about it when you resend it. If I remember well the logic was more or less like this: - More idle cores means run few running cores at high frequency - Less idle cores means don't run them at very high frequencies Right? This is correct. Also, the underlying SoC - Exynos4412 has 4 cores with option to set frequency only on all of them. What about making it as simple as: - changing the ondemand governor only instead of adding a new governor My goal is to not touch the ondemand code. It has matured, so I would like to leave it as it is. - Keeping the bahavior as is for all platforms not publishing boost frequencies This is also done - you get the LAB configuration specified in the DT for the particular platform/board. - If more cores are idle, enable switching to boost frequencies and take them into consideration all the time. I'm not sure if I have understood you, but something like that is also performed in the code. - If less cores are idle, disable boost frequencies.. As written above. Lets discuss this first and then I will get into the very details of your implementation. Discussion about above functionalities requires consulting the implementation to be sure that our opinions are the same. -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- 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/
Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
[Adding Linaro lists in cc as there are few people here working on power/thermal stuff.] On 24 March 2014 15:30, Lukasz Majewski l.majew...@samsung.com wrote: On 4 March 2014 15:57, Lukasz Majewski l.majew...@samsung.com wrote: I think, that LAB name is with us for some time, so it would be a pity to discard it. It doesn't matter with Mainline how you do naming initially for your code :) We need to pick the right name now, and the decision should be made now (after discussions obviously) :) What about making it as simple as: - changing the ondemand governor only instead of adding a new governor My goal is to not touch the ondemand code. It has matured, so I would like to leave it as it is. Because the boost feature is already part of CPUFreq core, I think its better if we enhance current governors to use it. So, I would like to make this part of existing governors. Not only ondemand but maybe conservative as well.. Also, I feel we maynot necessarily move this piece of code into cpufreq. All you are doing is thermal management here :) If we are sure we will not burn out our SoC (When many cores are idle), run at max freq (if there is enough load of course :)).. And if there are chances that we might burn our chip (when very few cores are idle), don't run on boost frequencies.. This is actually a 'cooling' device :) Think of it this way: CPUFreq will provide a range of frequency which SoC's can use. And then based on some conditions we may or may not want to run on these frequencies. @Zhang/Eduardo: Can we have your inputs here as well ? This may look hard but we need to design things in the best possible way for managing things better in future. Lets see what others have to say on this. -- 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/
Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
Hi Viresh, > On 17 March 2014 21:08, Lukasz Majewski > wrote: > >> Despite this patch set is working and applicable on top of > >> 3.14-rc5, please regard it solely as a pure RFC. > >> > >> This patch provides support for LAB governor build on top of > >> ondemand. Previous version of LAB can be found here: > >> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > >> > >> LAB short reminder: > >> > >> LAB uses information about how many cores are in "idle" state (the > >> core idleness is represented as the value between 0 and 100) and > >> the overall load of the system (from 0 to 100) to decide about > >> frequency to be set. It is extremely useful with SoCs like > >> Exynos4412, which can set only one frequency for all cores. > >> > >> Important design decisions: > >> > >> - Reuse well established ondemand governor's internal code. To do > >> this I had to expose some previously static internal ondemand code. > >> This allowed smaller LAB code when compared to previous version. > >> > >> - LAB works on top of ondemand, which means that one via device > >> tree attributes can specify if and when e.g. BOOST shall be > >> enabled or if any particular frequency shall be imposed. For > >> situation NOT important from the power consumption reduction > >> viewpoint the ondemand is used to set proper frequency. > >> > >> - It is only possible to either compile in or not the LAB into the > >> kernel. There is no "M" option for Kconfig. It is done on purpose, > >> since ondemand itself can be also compiled as a module and then it > >> would be possible to remove ondemand when LAB is working on top of > >> it. > >> > >> - The LAB operation is specified (and thereof extendable) via > >> device tree lab-ctrl-freq attribute defined at /cpus/cpu0. > >> > >> > >> Problems: > >> - How the governor will work for big.LITTLE systems (especially > >> Global Task Scheduling). > >> - Will there be agreement to expose internal ondemand code to be > >> reused for more specialized governors. > >> > >> Test HW: > >> Exynos4412 - Trats2 board. > >> Above patches were posted on top of Linux 3.14-rc5 > >> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6) > >> > > > > Any comments about those patches? > > Sorry for being late on reviewing these.. > > I tried to go through the patches but didn't looked at the minutest > of the details. Its been a long time when you first sent this > patchset. And the memories have corrupted by now :) .. Unfortunately memory is volatile ... since LAB governor is a follow up of BOOST, which review and inclusion took considerable time, some details could be forgotten. > > To get context back, can we discuss again the fundamentals behind > this new governor you are proposing. And then we can discuss about > it again, its pros/cons, etc.. Please consider following links: The original implementation - threads: http://thread.gmane.org/gmane.linux.power-management.general/32523/match=lab http://thread.gmane.org/gmane.linux.kernel/1484746/match=lab LAB justification data: http://article.gmane.org/gmane.linux.kernel/1472381 > People are reluctant in getting another governor in and want to give > existing governors a try if possible. As I've stated in the covering letter, this code is an extension of Ondemand. This is totally different from what have been posted previously (v1, v2). The first LAB proposal was written with some parts copied from Ondemand. It was a separate, standalone governor. The approach proposed in those patches is very different. It simply reuses Ondemand code as much as possible (timers, default attributes exported to sysfs, etc.). On top of the Ondemand we have the LAB, which thereof is its optional extension. The existing code is reused and can be easily extracted as a common code. > > So, please explain the basics behind your governor again and then > we can put our arguments again.. > I hope that provided overview is sufficient. More in depth information can be found in posted patches or provided LKML archives. > -- > viresh -- Best regards, Lukasz Majewski Samsung R Institute Poland (SRPOL) | Linux Platform Group -- 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/
Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
On 17 March 2014 21:08, Lukasz Majewski wrote: >> Despite this patch set is working and applicable on top of 3.14-rc5, >> please regard it solely as a pure RFC. >> >> This patch provides support for LAB governor build on top of ondemand. >> Previous version of LAB can be found here: >> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq >> >> LAB short reminder: >> >> LAB uses information about how many cores are in "idle" state (the >> core idleness is represented as the value between 0 and 100) and the >> overall load of the system (from 0 to 100) to decide about frequency >> to be set. It is extremely useful with SoCs like Exynos4412, which >> can set only one frequency for all cores. >> >> Important design decisions: >> >> - Reuse well established ondemand governor's internal code. To do this >> I had to expose some previously static internal ondemand code. >> This allowed smaller LAB code when compared to previous version. >> >> - LAB works on top of ondemand, which means that one via device tree >> attributes can specify if and when e.g. BOOST shall be enabled or >> if any particular frequency shall be imposed. For situation NOT >> important from the power consumption reduction viewpoint the ondemand >> is used to set proper frequency. >> >> - It is only possible to either compile in or not the LAB into the >> kernel. There is no "M" option for Kconfig. It is done on purpose, >> since ondemand itself can be also compiled as a module and then it >> would be possible to remove ondemand when LAB is working on top of it. >> >> - The LAB operation is specified (and thereof extendable) via device >> tree lab-ctrl-freq attribute defined at /cpus/cpu0. >> >> >> Problems: >> - How the governor will work for big.LITTLE systems (especially >> Global Task Scheduling). >> - Will there be agreement to expose internal ondemand code to be >> reused for more specialized governors. >> >> Test HW: >> Exynos4412 - Trats2 board. >> Above patches were posted on top of Linux 3.14-rc5 >> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6) >> > > Any comments about those patches? Sorry for being late on reviewing these.. I tried to go through the patches but didn't looked at the minutest of the details. Its been a long time when you first sent this patchset. And the memories have corrupted by now :) .. To get context back, can we discuss again the fundamentals behind this new governor you are proposing. And then we can discuss about it again, its pros/cons, etc.. I tried to go to earlier threads but I think we better do it again.. People are reluctant in getting another governor in and want to give existing governors a try if possible. So, please explain the basics behind your governor again and then we can put our arguments again.. -- viresh -- 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/
Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
On 17 March 2014 21:08, Lukasz Majewski l.majew...@samsung.com wrote: Despite this patch set is working and applicable on top of 3.14-rc5, please regard it solely as a pure RFC. This patch provides support for LAB governor build on top of ondemand. Previous version of LAB can be found here: http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq LAB short reminder: LAB uses information about how many cores are in idle state (the core idleness is represented as the value between 0 and 100) and the overall load of the system (from 0 to 100) to decide about frequency to be set. It is extremely useful with SoCs like Exynos4412, which can set only one frequency for all cores. Important design decisions: - Reuse well established ondemand governor's internal code. To do this I had to expose some previously static internal ondemand code. This allowed smaller LAB code when compared to previous version. - LAB works on top of ondemand, which means that one via device tree attributes can specify if and when e.g. BOOST shall be enabled or if any particular frequency shall be imposed. For situation NOT important from the power consumption reduction viewpoint the ondemand is used to set proper frequency. - It is only possible to either compile in or not the LAB into the kernel. There is no M option for Kconfig. It is done on purpose, since ondemand itself can be also compiled as a module and then it would be possible to remove ondemand when LAB is working on top of it. - The LAB operation is specified (and thereof extendable) via device tree lab-ctrl-freq attribute defined at /cpus/cpu0. Problems: - How the governor will work for big.LITTLE systems (especially Global Task Scheduling). - Will there be agreement to expose internal ondemand code to be reused for more specialized governors. Test HW: Exynos4412 - Trats2 board. Above patches were posted on top of Linux 3.14-rc5 (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6) Any comments about those patches? Sorry for being late on reviewing these.. I tried to go through the patches but didn't looked at the minutest of the details. Its been a long time when you first sent this patchset. And the memories have corrupted by now :) .. To get context back, can we discuss again the fundamentals behind this new governor you are proposing. And then we can discuss about it again, its pros/cons, etc.. I tried to go to earlier threads but I think we better do it again.. People are reluctant in getting another governor in and want to give existing governors a try if possible. So, please explain the basics behind your governor again and then we can put our arguments again.. -- viresh -- 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/
Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
Hi Viresh, On 17 March 2014 21:08, Lukasz Majewski l.majew...@samsung.com wrote: Despite this patch set is working and applicable on top of 3.14-rc5, please regard it solely as a pure RFC. This patch provides support for LAB governor build on top of ondemand. Previous version of LAB can be found here: http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq LAB short reminder: LAB uses information about how many cores are in idle state (the core idleness is represented as the value between 0 and 100) and the overall load of the system (from 0 to 100) to decide about frequency to be set. It is extremely useful with SoCs like Exynos4412, which can set only one frequency for all cores. Important design decisions: - Reuse well established ondemand governor's internal code. To do this I had to expose some previously static internal ondemand code. This allowed smaller LAB code when compared to previous version. - LAB works on top of ondemand, which means that one via device tree attributes can specify if and when e.g. BOOST shall be enabled or if any particular frequency shall be imposed. For situation NOT important from the power consumption reduction viewpoint the ondemand is used to set proper frequency. - It is only possible to either compile in or not the LAB into the kernel. There is no M option for Kconfig. It is done on purpose, since ondemand itself can be also compiled as a module and then it would be possible to remove ondemand when LAB is working on top of it. - The LAB operation is specified (and thereof extendable) via device tree lab-ctrl-freq attribute defined at /cpus/cpu0. Problems: - How the governor will work for big.LITTLE systems (especially Global Task Scheduling). - Will there be agreement to expose internal ondemand code to be reused for more specialized governors. Test HW: Exynos4412 - Trats2 board. Above patches were posted on top of Linux 3.14-rc5 (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6) Any comments about those patches? Sorry for being late on reviewing these.. I tried to go through the patches but didn't looked at the minutest of the details. Its been a long time when you first sent this patchset. And the memories have corrupted by now :) .. Unfortunately memory is volatile ... since LAB governor is a follow up of BOOST, which review and inclusion took considerable time, some details could be forgotten. To get context back, can we discuss again the fundamentals behind this new governor you are proposing. And then we can discuss about it again, its pros/cons, etc.. Please consider following links: The original implementation - threads: http://thread.gmane.org/gmane.linux.power-management.general/32523/match=lab http://thread.gmane.org/gmane.linux.kernel/1484746/match=lab LAB justification data: http://article.gmane.org/gmane.linux.kernel/1472381 People are reluctant in getting another governor in and want to give existing governors a try if possible. As I've stated in the covering letter, this code is an extension of Ondemand. This is totally different from what have been posted previously (v1, v2). The first LAB proposal was written with some parts copied from Ondemand. It was a separate, standalone governor. The approach proposed in those patches is very different. It simply reuses Ondemand code as much as possible (timers, default attributes exported to sysfs, etc.). On top of the Ondemand we have the LAB, which thereof is its optional extension. The existing code is reused and can be easily extracted as a common code. So, please explain the basics behind your governor again and then we can put our arguments again.. I hope that provided overview is sufficient. More in depth information can be found in posted patches or provided LKML archives. -- viresh -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- 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/
Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
Dear all, > Despite this patch set is working and applicable on top of 3.14-rc5, > please regard it solely as a pure RFC. > > This patch provides support for LAB governor build on top of ondemand. > Previous version of LAB can be found here: > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > LAB short reminder: > > LAB uses information about how many cores are in "idle" state (the > core idleness is represented as the value between 0 and 100) and the > overall load of the system (from 0 to 100) to decide about frequency > to be set. It is extremely useful with SoCs like Exynos4412, which > can set only one frequency for all cores. > > Important design decisions: > > - Reuse well established ondemand governor's internal code. To do this > I had to expose some previously static internal ondemand code. > This allowed smaller LAB code when compared to previous version. > > - LAB works on top of ondemand, which means that one via device tree > attributes can specify if and when e.g. BOOST shall be enabled or > if any particular frequency shall be imposed. For situation NOT > important from the power consumption reduction viewpoint the ondemand > is used to set proper frequency. > > - It is only possible to either compile in or not the LAB into the > kernel. There is no "M" option for Kconfig. It is done on purpose, > since ondemand itself can be also compiled as a module and then it > would be possible to remove ondemand when LAB is working on top of it. > > - The LAB operation is specified (and thereof extendable) via device > tree lab-ctrl-freq attribute defined at /cpus/cpu0. > > > Problems: > - How the governor will work for big.LITTLE systems (especially > Global Task Scheduling). > - Will there be agreement to expose internal ondemand code to be > reused for more specialized governors. > > Test HW: > Exynos4412 - Trats2 board. > Above patches were posted on top of Linux 3.14-rc5 > (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6) > Any comments about those patches? > Lukasz Majewski (5): > cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods > cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to > support LAB > cpufreq:LAB:lab Add LAB governor code > cpufreq:LAB:Kconfig Add LAB definitions to Kconfig > cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor > > arch/arm/boot/dts/exynos4412-trats2.dts | 29 ++ > drivers/cpufreq/Kconfig | 28 ++ > drivers/cpufreq/Makefile|1 + > drivers/cpufreq/cpufreq_governor.c |7 + > drivers/cpufreq/cpufreq_governor.h | 12 + > drivers/cpufreq/cpufreq_lab.c | 457 > +++ > drivers/cpufreq/cpufreq_ondemand.c | 24 +- 7 files changed, > 550 insertions(+), 8 deletions(-) create mode 100644 > drivers/cpufreq/cpufreq_lab.c > -- Best regards, Lukasz Majewski Samsung R Institute Poland (SRPOL) | Linux Platform Group -- 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/
Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
Dear all, Despite this patch set is working and applicable on top of 3.14-rc5, please regard it solely as a pure RFC. This patch provides support for LAB governor build on top of ondemand. Previous version of LAB can be found here: http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq LAB short reminder: LAB uses information about how many cores are in idle state (the core idleness is represented as the value between 0 and 100) and the overall load of the system (from 0 to 100) to decide about frequency to be set. It is extremely useful with SoCs like Exynos4412, which can set only one frequency for all cores. Important design decisions: - Reuse well established ondemand governor's internal code. To do this I had to expose some previously static internal ondemand code. This allowed smaller LAB code when compared to previous version. - LAB works on top of ondemand, which means that one via device tree attributes can specify if and when e.g. BOOST shall be enabled or if any particular frequency shall be imposed. For situation NOT important from the power consumption reduction viewpoint the ondemand is used to set proper frequency. - It is only possible to either compile in or not the LAB into the kernel. There is no M option for Kconfig. It is done on purpose, since ondemand itself can be also compiled as a module and then it would be possible to remove ondemand when LAB is working on top of it. - The LAB operation is specified (and thereof extendable) via device tree lab-ctrl-freq attribute defined at /cpus/cpu0. Problems: - How the governor will work for big.LITTLE systems (especially Global Task Scheduling). - Will there be agreement to expose internal ondemand code to be reused for more specialized governors. Test HW: Exynos4412 - Trats2 board. Above patches were posted on top of Linux 3.14-rc5 (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6) Any comments about those patches? Lukasz Majewski (5): cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to support LAB cpufreq:LAB:lab Add LAB governor code cpufreq:LAB:Kconfig Add LAB definitions to Kconfig cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor arch/arm/boot/dts/exynos4412-trats2.dts | 29 ++ drivers/cpufreq/Kconfig | 28 ++ drivers/cpufreq/Makefile|1 + drivers/cpufreq/cpufreq_governor.c |7 + drivers/cpufreq/cpufreq_governor.h | 12 + drivers/cpufreq/cpufreq_lab.c | 457 +++ drivers/cpufreq/cpufreq_ondemand.c | 24 +- 7 files changed, 550 insertions(+), 8 deletions(-) create mode 100644 drivers/cpufreq/cpufreq_lab.c -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- 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/
[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
Despite this patch set is working and applicable on top of 3.14-rc5, please regard it solely as a pure RFC. This patch provides support for LAB governor build on top of ondemand. Previous version of LAB can be found here: http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq LAB short reminder: LAB uses information about how many cores are in "idle" state (the core idleness is represented as the value between 0 and 100) and the overall load of the system (from 0 to 100) to decide about frequency to be set. It is extremely useful with SoCs like Exynos4412, which can set only one frequency for all cores. Important design decisions: - Reuse well established ondemand governor's internal code. To do this I had to expose some previously static internal ondemand code. This allowed smaller LAB code when compared to previous version. - LAB works on top of ondemand, which means that one via device tree attributes can specify if and when e.g. BOOST shall be enabled or if any particular frequency shall be imposed. For situation NOT important from the power consumption reduction viewpoint the ondemand is used to set proper frequency. - It is only possible to either compile in or not the LAB into the kernel. There is no "M" option for Kconfig. It is done on purpose, since ondemand itself can be also compiled as a module and then it would be possible to remove ondemand when LAB is working on top of it. - The LAB operation is specified (and thereof extendable) via device tree lab-ctrl-freq attribute defined at /cpus/cpu0. Problems: - How the governor will work for big.LITTLE systems (especially Global Task Scheduling). - Will there be agreement to expose internal ondemand code to be reused for more specialized governors. Test HW: Exynos4412 - Trats2 board. Above patches were posted on top of Linux 3.14-rc5 (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6) Lukasz Majewski (5): cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to support LAB cpufreq:LAB:lab Add LAB governor code cpufreq:LAB:Kconfig Add LAB definitions to Kconfig cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor arch/arm/boot/dts/exynos4412-trats2.dts | 29 ++ drivers/cpufreq/Kconfig | 28 ++ drivers/cpufreq/Makefile|1 + drivers/cpufreq/cpufreq_governor.c |7 + drivers/cpufreq/cpufreq_governor.h | 12 + drivers/cpufreq/cpufreq_lab.c | 457 +++ drivers/cpufreq/cpufreq_ondemand.c | 24 +- 7 files changed, 550 insertions(+), 8 deletions(-) create mode 100644 drivers/cpufreq/cpufreq_lab.c -- 1.7.10.4 -- 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/
[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
Despite this patch set is working and applicable on top of 3.14-rc5, please regard it solely as a pure RFC. This patch provides support for LAB governor build on top of ondemand. Previous version of LAB can be found here: http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq LAB short reminder: LAB uses information about how many cores are in idle state (the core idleness is represented as the value between 0 and 100) and the overall load of the system (from 0 to 100) to decide about frequency to be set. It is extremely useful with SoCs like Exynos4412, which can set only one frequency for all cores. Important design decisions: - Reuse well established ondemand governor's internal code. To do this I had to expose some previously static internal ondemand code. This allowed smaller LAB code when compared to previous version. - LAB works on top of ondemand, which means that one via device tree attributes can specify if and when e.g. BOOST shall be enabled or if any particular frequency shall be imposed. For situation NOT important from the power consumption reduction viewpoint the ondemand is used to set proper frequency. - It is only possible to either compile in or not the LAB into the kernel. There is no M option for Kconfig. It is done on purpose, since ondemand itself can be also compiled as a module and then it would be possible to remove ondemand when LAB is working on top of it. - The LAB operation is specified (and thereof extendable) via device tree lab-ctrl-freq attribute defined at /cpus/cpu0. Problems: - How the governor will work for big.LITTLE systems (especially Global Task Scheduling). - Will there be agreement to expose internal ondemand code to be reused for more specialized governors. Test HW: Exynos4412 - Trats2 board. Above patches were posted on top of Linux 3.14-rc5 (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6) Lukasz Majewski (5): cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to support LAB cpufreq:LAB:lab Add LAB governor code cpufreq:LAB:Kconfig Add LAB definitions to Kconfig cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor arch/arm/boot/dts/exynos4412-trats2.dts | 29 ++ drivers/cpufreq/Kconfig | 28 ++ drivers/cpufreq/Makefile|1 + drivers/cpufreq/cpufreq_governor.c |7 + drivers/cpufreq/cpufreq_governor.h | 12 + drivers/cpufreq/cpufreq_lab.c | 457 +++ drivers/cpufreq/cpufreq_ondemand.c | 24 +- 7 files changed, 550 insertions(+), 8 deletions(-) create mode 100644 drivers/cpufreq/cpufreq_lab.c -- 1.7.10.4 -- 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/
