Hi Viresh, > Hi Viresh, > > > On 17 March 2014 21:08, Lukasz Majewski <l.majewski@xxxxxxxxxxx> > > 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&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
