public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Luca Zini <luca.zini@gmail.com>
To: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
	aagaande@gmail.com, rdelcueto@hotmail.com, mingo@elte.hu,
	"linux-kernel" <linux-kernel@vger.kernel.org>,
	Alex Chiang <achiang@hp.com>
Subject: Re: scheduler vs hardware? (was Re: another i7  (linux) bug?)
Date: Fri, 22 Jan 2010 12:22:28 +0100	[thread overview]
Message-ID: <201001221222.28516.luca.zini@gmail.com> (raw)
In-Reply-To: <1264152860.4283.1442.camel@laptop>

[-- Attachment #1: Type: Text/Plain, Size: 1959 bytes --]

First of all sorry for misunderstanding with Alex Chiang, I was trying to 
collect some data from other i7 mobile users to try to isolate the problem 
before posting.

I tried different things: I disabled speedstep from the bios and the results 
where more sensible (higher priority lower execution time). The same thing 
happens if I disable throttling  by software selecting "aggressive powersave" 
settings.

So I suppose that is something related directly or indirectly to frequency 
scaling or turbo boost (unfortunately I have no bios option to disable only 
turbo boost) 
Here are the results of the same test of Peter Zijlstra

time  sudo nice -n 19 lame -b 256 -V0 -h youcantdothat.wav  2&> /dev/null

real    0m1.105s
user    0m1.090s
sys     0m0.010s

time  sudo nice -n 0 lame -b 256 -V0 -h youcantdothat.wav  2&> /dev/null

real    0m1.108s
user    0m1.100s
sys     0m0.010s

time  sudo nice -n -20 lame -b 256 -V0 -h youcantdothat.wav  2&> /dev/null

real    0m1.354s
user    0m1.330s
sys     0m0.000s

They are almost the same results that I obtained before.
Looking at top there are no other process that is using the cpu  (main are 
Xorg and kopete).

I tested this on  2.6.31-17-server (ubuntu 9.10) 2.6.31-17-generic (ubuntu 
9.10) and the default kernel of fedora 12 (live cd).
As soon as possible I'll try 33-rc5 as requested by Mike Galbraith (now I 
can't shut down the computer).

Ok, a last minute update! 
I slightly modified i7z to save a log to disk. If i7z output are reliable I 
suppose that it can show is the problem:
with nice set to 19 a processor 3 reach the maximum speed,  with nice set to 
-20 its maximum value is 300-400 mhz under the maximum value. (I attach the 
two logs named as the nice level used obtained running lame on a bigger file)
Please note that logs may have some value read before and/or after the 
start/end of the running process (lame).

The next update will be the results with 33-rc5 kernel.

Luca

[-- Attachment #2: log-20 --]
[-- Type: text/plain, Size: 1449 bytes --]

	Processor 0:  1062.13 (7.99x)	   1	99.7	   0	98.5
	Processor 1:  1246.75 (9.37x)	   1	99.8	   0	  99
	Processor 2:  1113.41 (8.37x)	   1	99.8	   0	98.4
	Processor 3:  1477.30 (11.11x)	4.67	95.7	   0	85.7
	Processor 0:  1109.70 (8.34x)	   1	99.7	2.93	95.8
	Processor 1:  2316.51 (17.42x)	 5.5	  92	   0	91.7
	Processor 2:  1114.96 (8.38x)	   1	99.8	14.9	83.7
	Processor 3:  1225.48 (9.21x)	9.95	92.4	1.33	67.6
	Processor 0:  1877.15 (14.11x)	   1	99.8	29.6	69.9
	Processor 1:  1914.75 (14.40x)	   1	99.2	   1	98.1
	Processor 2:  1955.22 (14.70x)	   1	99.8	   0	99.4
	Processor 3:  2402.49 (18.06x)	38.8	41.6	   0	   0
	Processor 0:  2114.28 (15.90x)	  12	84.1	   0	35.4
	Processor 1:  1528.62 (11.49x)	   1	99.8	25.4	73.2
	Processor 2:  1582.10 (11.90x)	   1	99.9	74.2	25.2
	Processor 3:  2359.66 (17.74x)	14.6	78.3	18.6	  56
	Processor 0:  2242.78 (16.86x)	16.3	77.1	   0	   0
	Processor 1:  1591.62 (11.97x)	   1	99.9	87.9	10.9
	Processor 2:  1885.84 (14.18x)	   1	 100	99.2	   1
	Processor 3:  2035.81 (15.31x)	1.77	97.7	  15	75.4
	Processor 0:  2280.59 (17.15x)	18.3	73.8	   1	70.4
	Processor 1:  1906.72 (14.34x)	   1	99.7	26.9	  72
	Processor 2:  1778.56 (13.37x)	   1	99.9	70.9	28.6
	Processor 3:  1077.58 (8.10x)	8.56	94.2	3.66	4.79
	Processor 0:  2009.19 (15.11x)	7.07	91.1	   1	88.3
	Processor 1:  1708.96 (12.85x)	   1	99.8	37.3	61.5
	Processor 2:  1673.01 (12.58x)	   1	99.9	13.4	85.9
	Processor 3:  1421.09 (10.68x)	12.1	89.2	   1	21.8

[-- Attachment #3: log19 --]
[-- Type: text/plain, Size: 1238 bytes --]

	Processor 0:  935.30 (7.03x)	   1	99.8	   0	73.4
	Processor 1:  938.46 (7.06x)	   1	99.9	   0	98.3
	Processor 2:  932.33 (7.01x)	   1	99.9	   0	97.7
	Processor 3:  1017.69 (7.65x)	6.09	96.1	   0	92.1
	Processor 0:  1040.73 (7.83x)	   1	99.8	   0	99.1
	Processor 1:  1062.37 (7.99x)	   1	99.7	   0	96.1
	Processor 2:  1047.94 (7.88x)	   1	99.8	   1	97.7
	Processor 3:  1941.75 (14.60x)	11.1	86.5	2.98	81.5
	Processor 0:  1940.64 (14.59x)	   1	99.5	   0	72.7
	Processor 1:  1600.11 (12.03x)	   1	99.8	11.5	  86
	Processor 2:  2141.58 (16.10x)	   1	 100	99.6	   1
	Processor 3:  2760.11 (20.75x)	83.2	   0	4.33	11.6
	Processor 0:  2331.59 (17.53x)	   1	99.4	5.98	  93
	Processor 1:  2287.80 (17.20x)	   1	99.8	   0	97.6
	Processor 2:  2122.39 (15.96x)	   1	 100	88.5	11.1
	Processor 3:  2774.36 (20.86x)	99.9	   0	   0	   0
	Processor 0:  2322.64 (17.46x)	   1	99.5	   1	98.6
	Processor 1:  2275.29 (17.11x)	   1	99.8	   1	97.9
	Processor 2:  2268.43 (17.06x)	   1	99.8	   0	99.5
	Processor 3:  2779.36 (20.90x)	99.9	   0	   0	   0
	Processor 0:  2277.58 (17.12x)	   1	99.8	   0	99.6
	Processor 1:  2372.66 (17.84x)	   1	99.5	   0	99.2
	Processor 2:  2346.90 (17.65x)	   1	99.8	   0	99.5
	Processor 3:  2783.34 (20.93x)	99.9	   0	   0	   0

  reply	other threads:[~2010-01-22 11:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <201001211258.23499.luca.zini@gmail.com>
2010-01-21 21:54 ` scheduler vs hardware? (was Re: another i7 (linux) bug?) Alex Chiang
2010-01-22  7:19   ` Mike Galbraith
2010-01-22  8:51     ` Peter Zijlstra
2010-01-22  9:10       ` Mike Galbraith
2010-01-22  9:25       ` Mike Galbraith
2010-01-22  9:34         ` Peter Zijlstra
2010-01-22 11:22           ` Luca Zini [this message]
2010-01-22 15:58             ` Chris Friesen
2010-01-23  9:43       ` Ingo Molnar
2010-01-22 20:15     ` Luca Zini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201001221222.28516.luca.zini@gmail.com \
    --to=luca.zini@gmail.com \
    --cc=aagaande@gmail.com \
    --cc=achiang@hp.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=rdelcueto@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox