linux-kernel - Re: [RFC] [PATCH] timer: Added usleep[_range][

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 28 Jun 2010 12:39:39 -0700
From:	Daniel Walker <dwalker@...eaurora.org>
To:	Patrick Pannuto <ppannuto@...eaurora.org>
Cc:	linux-kernel@...r.kernel.org, sboyd@...eaurora.org,
	tglx@...utronix.de, mingo@...e.hu, heiko.carstens@...ibm.com,
	eranian@...gle.com, schwidefsky@...ibm.com,
	linux-arm-msm@...r.kernel.org
Subject: Re: [RFC] [PATCH] timer: Added usleep[_range][_interruptable] timer

On Mon, 2010-06-28 at 11:03 -0700, Patrick Pannuto wrote:

> Well here we go then.

Great.


> *** RESULTS ***
> 
> Complete results are attached (please forgive the ugly stats.py, it
> evolved; it's functional for the task at hand, but certainly not pretty).
> 
> --> Long results also at end of email
> 
> From the final results, after 240s:
> 
> TIME	STATE		#TIMES CALLED	 TIME IN STATE		| DELTA FROM ORG
> 
> ////////////////////////////////////////////////////////////////////////////////
> === origin (10 samples) =================================== RUNTIME: 241.535 ===

What's the 10 samples here?

> 240	idle-spin    --	2.3              1.45001e-05     
> 240	not-idle     --	88368.2          67.8311703321   
> 240	idle-request --	88367.2          23337.6322655   
> 240	idle-wfi     --	88364.9          172.296383696

I'm going to assume you did ten in "origin" (i.e. control runs) and
averaged. However, you need to explicitly say that ..

What units is "time in state", and what interfacing does the timing? Are
these states in order from least power saving to most power savings?

> === over1000 (10 samples) ====== (delta: -0.00999999998604) RUNTIME: 241.525 ===
> 240	idle-spin    --	3.1              1.91666e-05      	| 4.6665e-06
> 240	not-idle     --	88723.9          65.6361809172    	| -2.1949894149
> 240	idle-request --	88722.9          23311.9855603    	| -25.6467051707
> 240	idle-wfi     --	88719.8          174.493487111    	| 2.1971034149
> === over500 (10 samples) ======== (delta: -0.0339999999851) RUNTIME: 241.501 ===
> 240	idle-spin    --	2.3              1.88334e-05      	| 4.3333e-06
> 240	not-idle     --	88636.3          67.0242803241    	| -0.806890008
> 240	idle-request --	88635.3          23280.1632631    	| -57.469002442
> 240	idle-wfi     --	88633.0          173.077055869    	| 0.7806721723
> === over100 (10 samples) ======== (delta: -0.0539999999921) RUNTIME: 241.481 ===
> 240	idle-spin    --	0.9              6.6666e-06       	| -7.8335e-06
> 240	not-idle     --	88599.0          67.190273164     	| -0.6408971681
> 240	idle-request --	88597.9          23253.4797828    	| -84.1524827638
> 240	idle-wfi     --	88597.0          172.884529866    	| 0.5881461694
> === equal100 (10 samples) ================== (delta: -0.025) RUNTIME: 241.51 ===
> 240	idle-spin    --	1.4              9.5002e-06       	| -4.9999e-06
> 240	not-idle     --	88685.9          66.5067348407    	| -1.3244354914
> 240	idle-request --	88684.9          23294.4341497    	| -43.1981158192
> 240	idle-wfi     --	88683.5          173.60379269     	| 1.3074089936
> === equal50 (10 samples) ======== (delta: -0.0289999999804) RUNTIME: 241.506 ===
> 240	idle-spin    --	2.0              9.6664e-06       	| -4.8337e-06
> 240	not-idle     --	88537.4          65.8619214556    	| -1.9692488765
> 240	idle-request --	88536.4          22979.3665406    	| -358.265724952
> 240	idle-wfi     --	88534.4          174.247270576    	| 1.9508868794
> 
> 
> There appears to be very little change outside of noise from origin through
> equal100, however, once equal50 is reached, there is a noticeable change.

it all looks pretty noisy still, but it could be that your just
providing too much information ...

Ok, so the idle-request state had residency of 22979us (guessing units)
in equal50, and 23338us in the control. Which is %1.5 less. I would
think you want more residency rather than less right?

Replacing 50us udelays with timers will cause more timers to trigger at
a high frequency, which would cause you to be running timer code more
often rather than doing something else (maybe being in a sleep state).
So the number make some sense.

Does over100 include everything from 100 to 1000 ?

Daniel

--
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/