[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[l.majewski@samsung.com (Lukasz Majewski)]

Hi Viresh,

> Hi Viresh,
> 
> > On 17 March 2014 21:08, Lukasz Majewski <l.majewski@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 R&D Institute Poland (SRPOL) | Linux Platform Group