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

[Lukasz Majewski]

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

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/