Date:	Tue, 20 Aug 2013 10:11:47 +0200
From:	Lukasz Majewski <l.majewski@...sung.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Viresh Kumar <viresh.kumar@...aro.org>,
	Zhang Rui <rui.zhang@...el.com>,
	Eduardo Valentin <eduardo.valentin@...com>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Jonghwa Lee <jonghwa3.lee@...sung.com>,
	Lukasz Majewski <l.majewski@...ess.pl>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Myungjoo Ham <myungjoo.ham@...sung.com>,
	"R, Durgadoss" <durgadoss.r@...el.com>
Subject: Re: [PATCH v7 0/7] cpufreq:boost: CPU Boost mode support

On Tue, 20 Aug 2013 01:29:20 +0200 Rafael J. Wysocki rjw@...k.pl wrote,
> On Monday, August 19, 2013 08:50:37 AM Lukasz Majewski wrote:
> > On Mon, 19 Aug 2013 12:08:26 +0530 Viresh Kumar
> > viresh.kumar@...aro.org wrote,
> > > On 13 August 2013 15:38, Lukasz Majewski <l.majewski@...sung.com>
> > > wrote:
> > > > This patch series introduces support for CPU overclocking
> > > > technique called Boost.
> > > >
> > > > It is a follow up of a LAB governor proposal. Boost is a LAB
> > > > component:
> > > > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> > > >
> > > > Boost unifies hardware based solution (e.g. Intel Nehalem) with
> > > > software oriented one (like the one done at Exynos).
> > > > For this reason cpufreq/freq_table code has been reorganized to
> > > > include common code.
> > > >
> > > > Important design decisions:
> > > > - Boost related code is compiled-in unconditionally to cpufreq
> > > > core and disabled by default. The cpufreq_driver is
> > > > responsibile for setting boost_supported flag and providing
> > > > set_boost callback(if HW support is needed). For software
> > > > managed boost, special Kconfig flag - CONFIG_CPU_FREQ_BOOST_SW
> > > > has been defined. It will be selected only when a target
> > > > platform has thermal framework properly configured.
> > > >
> > > > - struct cpufreq_driver has been extended with boost related
> > > > fields: -- boost_supported - when driver supports boosting
> > > >         -- boost_enabled - boost state
> > > >         -- set_boost - callback to function, which is necessary
> > > > to enable/disable boost
> > > >
> > > > - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost)
> > > > is visible _only_ when cpufreq driver supports Boost.
> > > >
> > > > - No special spin_lock for Boost was created. The one from
> > > > cpufreq core was reused.
> > > >
> > > > - The Boost code doesn't rely on any policy. When boost state is
> > > > changed, then the policy list is iterated and proper
> > > > adjustements are done.
> > > >
> > > > - To improve safety level, the thermal framework is also
> > > > extended to disable software boosting, when thermal trip point
> > > > is reached. Then it starts monitoring target temperature to
> > > > evaluate if boost can be enabled again. This emulates behaviour
> > > > similar to HW managed boost (like x86)
> > > >
> > > > Tested at HW:
> > > >        Exynos 4412 3.11-rc4 Linux
> > > >        Intel Core i7-3770 3.11-rc4 Linux
> > > >
> > > > Above patches were posted on top of linux_pm/linux-next with
> > > > following patches applied:
> > > >
> > > > cpufreq: exynos5440: Fix to skip when new frequency same as
> > > > current cpufreq: fix EXYNOS drivers selection
> > > >
> > > > Lukasz Majewski (7):
> > > >   cpufreq: Add boost frequency support in core
> > > >   cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with
> > > > common boost solution
> > > >   thermal:boost: Automatic enable/disable of BOOST feature
> > > >   cpufreq:boost:Kconfig: Provide support for software managed
> > > > BOOST cpufreq:exynos:Extend Exynos cpufreq driver to support
> > > > boost framework
> > > >   Documentation:cpufreq:boost: Update BOOST documentation
> > > >   cpufreq:exynos4x12: Change L0 driver data to
> > > > CPUFREQ_BOOST_FREQ
> > > 
> > > Hi Lukasz,
> > > 
> > 
> > Hi Viresh,
> > 
> > > I haven't found time yet to go through this series.. 
> > 
> > I've just started wondering if I had send those patches
> > correctly :-).
> > 
> > > I want to do a
> > > deep/careful review this time as these are almost the final
> > > patches.
> > 
> > Ok.
> > 
> > > 
> > > Will try to get over them by the end of this week..
> > 
> > Ok, I understand.
> 
> Do I assume correctly that this stuff has been tested on
> ACPI-compatible x86 with acpi-cpufreq and everything has worked
> correctly there?
> 
> Rafael
> 

Hi Rafael,

Following test configuration/test case (x86):

- DELL OptiPlex 9010 Intel Core i7-3770
- Linux repo: [kernel_pm_http/bleeding-edge] [kernel_pm_http/linux-next]
	SHA1: a238ea5e20be7bea2b1fc951a024ecce770306b5 
	with v7 applied on top

- Linux version: 3.11-rc4 (patches v7) and 3.11-rc1 (v6)

- Ubuntu 11.10 (make bzImage + make all when module was needed)
- config_ubuntu_3_11 (the default one for ubuntu)
- KConfig:
	1. Disabled intel_pstate driver
	2. Enabled ACPI-Prosessor P state driver
	3. Legacy cpb sysfs knob support for AMD CPUs ON/OFF (which is a
	part of acpi-cpufreq.c driver).
	
- acpi-cpufreq driver was build as a module or was embedded in kernel
  (tested with modprobe -i / -r => no dmesg error|warning output)

- I was able to read/write (echo 0/1
  > /sys/devices/system/cpu/cpufreq/boost) => no output at dmesg -
  system was working stable.

Toolchain: gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)

Since I'm mostly working with ARM (exynos4412) and major work was done
with cpufreq core (and x86 related work was to move common code to
cpufreq core) tests mostly have been performed on ARM.

Tests on ARM:
- Stress tests with up to 4 scripts running to enable/disable boost
  sysfs attribute with random time interval (gzip < /dev/urandom
  > /dev/null). 
- Test to overheat the ARM target and look if boost+thermal cools down
  the device and enables boost again.
- LAB governor (which was already posted to ML) to boost when power
  envelope allows it.


-- 
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists