linux-kernel - Re: power increase issue on light load

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 29 Jun 2011 14:55:46 +0800
From:	"Alex,Shi" <alex.shi@...el.com>
To:	Nikhil Rao <ncrao@...gle.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"Chen, Tim C" <tim.c.chen@...el.com>,
	"Li, Shaohua" <shaohua.li@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Brown, Len" <len.brown@...el.com>
Subject: Re: power increase issue on light load

On Wed, 2011-06-29 at 11:22 +0800, Alex,Shi wrote:
> > 
> > Looking at the schedstat data Alex posted:
> > - Distribution of load balances across cores looks about the same.
> > - Load balancer does more idle balances on 3.0-rc4 as compared to
> > 2.6.39 on SMT and NUMA domains. Busy and newidle balances are a mixed
> > bag.
> > - I see far fewer affine wakeups on 3.0-rc4 as compared to 2.6.39.
> > About half as many affine wakeups on SMT and about a quarter as many
> > on NUMA.
> > 
> > I'm investigating the impact of the load resolution patchset on
> > effective load and wake affine calculations. This seems to be the most
> > obvious difference from the schedstat data.
> > 
> > Alex -- I have a couple of questions about your test setup and results.
> > - What is the impact on throughput of these benchmarks?
> 
> both on bltk-office and light load specpower, 10%/20%/30% load, the
> throughput almost have no change on my NHM-EP server and t410 laptop.
> > - Would it be possible to get a "perf sched" trace on these two kernels?

I tried the 'perf sched record' and then 'perf sched trace' as usage
show. but in fact, the 'perf sched' doesn't support 'trace' command now.
since the 'perf sched record' is using 'perf record -e sched:xxx' to do
record. I used 'perf record' directly. The follow info collected in 300'
on my NHM-EP for benchmark bltk-office. 

[alexs@...-ne01 ~]$ grep -e Events.*sched
linux-2.6/perf-report-3.0.0-rc5  
# Events: 11K sched:sched_wakeup
# Events: 1K sched:sched_wakeup_new
# Events: 24K sched:sched_switch
# Events: 3K sched:sched_migrate_task
# Events: 851  sched:sched_process_free
# Events: 1K sched:sched_process_exit
# Events: 1K sched:sched_process_wait
# Events: 1K sched:sched_process_fork
# Events: 12K sched:sched_stat_wait
# Events: 9K sched:sched_stat_sleep
# Events: 452  sched:sched_stat_iowait
# Events: 16K sched:sched_stat_runtime
[alexs@...-ne01 ~]$ 
[alexs@...-ne01 ~]$ 
[alexs@...-ne01 ~]$ grep -e
Events.*sched /mnt/linux-2.6.39/perf-report-2.6.39 
# Events: 5K sched:sched_wakeup
# Events: 615  sched:sched_wakeup_new
# Events: 11K sched:sched_switch
# Events: 2K sched:sched_migrate_task
# Events: 541  sched:sched_process_free
# Events: 692  sched:sched_process_exit
# Events: 1K sched:sched_process_wait
# Events: 615  sched:sched_process_fork
# Events: 6K sched:sched_stat_wait
# Events: 4K sched:sched_stat_sleep
# Events: 178  sched:sched_stat_iowait
# Events: 9K sched:sched_stat_runtime


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