Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Lukasz Majewski <l.majewski@samsung.com>]

[-- Attachment #1: Type: text/plain, Size: 3184 bytes --]

Hi Viresh,

> On 22 May 2013 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:
> >> On 3 May 2013 19:37, Jonghwa Lee <jonghwa3.lee@samsung.com> wrote:
> 
> > I think, that overclocking support is crucial here. As you pointed
> > out
> > - ondemand and conservative benefit from it. Therefore, I would urge
> >   for its mainline acceptance.
> >
> > (code for reference)
> > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> >
> > In this RFC (patch 1/3), I've decided to put the burden of
> > overclocking support to platform code (cpufreq/exynos-cpufreq.c and
> > cpufreq/exynos4x12-cpufreq.c).
> >
> > Those changes aren't intrusive for other boards/archs. Moreover
> > overclocking is closely related to processor clocking/power
> > dissipation capabilities, so SoC specific code is a good place for
> > it.
> >
> >
> > What DO need a broad acceptance is the overclocking API proposed at:
> > include/linux/cpufreq.h
> >
> > This introduces interface to which others will be bind. It
> > shouldn't be difficult to implement overclocking at other SoCs (as
> > it was proposed for Exynos).
> >
> > Feedback is welcome, since I might have overlooked oddities present
> > at other SoCs.
> 
> Hi..
> 
> I am not talking about the minute details here... for example I
> didn't like the way overclocking support is implemented... It has to
> be a bit more framework oriented then driver...
> 
> What I am thinking right now is if it is worth to add both the
> features you are trying. i.e. overclocking and LAB..
> 
> So, requested you to give some figures... of ondemand with and without
> overclocking... Leave LAB for now...
> 
> Then we can give LAB a try with above...

Test HW Exynos4412 (4 Cores):
Kernel 3.8.3

Ondemand max freq: 1.4 GHz
Overclock max freq: 1.5 GHz


Ondemand improvement with and without overclocking (called by us
TurboBoost - TB):

Dhrystone has been built according to:
http://zenit.senecac.on.ca/wiki/index.php/Dhrystone_howto
It's Makefile is also attached.
------------------------------------------------

Dhrystone	# of Threads			
		1	2	3	4
ondemand	2054794	2061855	2097902	2090592
ondemand + TB	2290076	2205882	2281368 2290076

Improvement:	10%	7%	8%	9%
-------------------------------------------------

Electric charge [C]
(Avg) [A] * [second]	# of Threads			
		1	2	3	4
ondemand	1,334	1,837	2,296	3,096
ondemand + TB	1,401	2,2025	2,907	4,34976
								
Power cost:	5%	17%	21%	29%
-------------------------------------------------

Execution time [second]	# of Threads			
		1	2	3	4
ondemand	2,827	2,8	2,787	2,872
ondemand + TB	2,622	2,694	2,667	2,76
				
				
Speedup:	-7%	-4%	-4%	-4%

-------------------------------------------------

"Real life" example:
time tar -czf linux-3.9.1.tar.gz linux-3.9.1/

		Avg current[mA]		Time[s]
Ondemand:	460			153	
Ondemand + TB:	512			144

Result:		+10%			-6%



Conclusion: 

The main use case for TB is to speed up execution of tasks packed to
one core. Other cores are then in IDLE state.

For a single core we can safely overclock, since we will not exceed its
power consumption and thermal limits.


-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group

[-- Attachment #2: Makefile --]
[-- Type: application/octet-stream, Size: 2180 bytes --]

#
#	Adjust for your system!
#
#	Common options for generic UNIX and Microsoft C (under DOS)
#	are listed here.  You can change them by switching the order,
#	placing the ones you want last.  Pay particular attention to
#	the HZ parameter, which may or may not be listed in some
#	header file on your system, such as <sys/param.h> or <limits.h>
#	(as CLK_TCK).  Even if it is listed, it may be incorrect.
#	Also, some operating systems (notably some (all?) versions
#	of Microport UNIX) lie about the time.  Sanity check with a
#	stopwatch.
#
#	For Microsoft C under DOS, you need a real make, not MSC make,
#	to run this Makefile.  The public domain "ndmake" will suffice.
#
CC=		cl			# C compiler name goes here (MSC)
CC=		cc			# C compiler name goes here (UNIX)
GCC=		arm-gcc

PROGS=		unix			# Programs to build (UNIX)

#TIME_FUNC=	-DMSC_CLOCK		# Use Microsoft clock() for measurement
#TIME_FUNC=	-DTIME			# Use time(2) for measurement
TIME_FUNC=	-DTIMES			# Use times(2) for measurement
#HZ=		50			# Frequency of times(2) clock ticks
HZ=		60			# Frequency of times(2) clock ticks
#HZ=		100			# Frequency of times(2) clock ticks
#HZ=		1			# Give bogus result unless changed!

STRUCTASSIGN=	-DNOSTRUCTASSIGN	# Compiler cannot assign structs
STRUCTASSIGN=				# Compiler can assign structs

ENUMS=		-DNOENUMS		# Compiler doesn't have enum type
ENUMS=					# Compiler does have enum type

OPTIMIZE=	-Ox -G2			# Optimization Level (MSC, 80286)
OPTIMIZE=	-O4			# Optimization Level (generic UNIX)
GCCOPTIM=       -O

LFLAGS=					#Loader Flags

CFLAGS=	$(OPTIMIZE) $(TIME_FUNC) -DHZ=$(HZ) $(ENUMS) $(STRUCTASSIGN) $(CFL)
GCCFLAGS= $(GCCOPTIM) $(TIME_FUNC) -DHZ=$(HZ) $(ENUMS) $(STRUCTASSIGN) $(CFL)

#
#		You shouldn't need to touch the rest
#
SRC=		dhry_1.c dhry_2.c
HDR=		dhry.h

UNIX_PROGS=	gcc_dry2 gcc_dry2reg

# Files added by rer:
FILES1=		README.RER clarify.doc Makefile submit.frm pure2_1.dif \
		dhry_c.dif
# Reinhold's files:
FILES2=		README RATIONALE $(HDR) $(SRC)
FILES3=		dhry.p

all:	$(PROGS)

unix:	$(UNIX_PROGS)

gcc_dry2:		$(SRC) $(HDR)
		$(GCC) $(GCCFLAGS) $(SRC) $(LFLAGS) -o $@

gcc_dry2reg:	$(SRC) $(HDR)
		$(GCC) $(GCCFLAGS) -DREG=register $(SRC) $(LFLAGS) -o $@