From: "Alex,Shi" <alex.shi@intel.com>
To: Nikhil Rao <ncrao@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
"mingo@elte.hu" <mingo@elte.hu>,
"Chen, Tim C" <tim.c.chen@intel.com>,
"Li, Shaohua" <shaohua.li@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Brown, Len" <len.brown@intel.com>
Subject: Re: power increase issue on light load
Date: Wed, 29 Jun 2011 11:22:44 +0800 [thread overview]
Message-ID: <1309317764.14604.92.camel@debian> (raw)
In-Reply-To: <CAOM-RdPBc2kcWDtUvTDe9PqQMq=u5qcEprDbC9guVi+wX+9bRg@mail.gmail.com>
>
> 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 will run the testing again and give you data later. but I didn't find
more useful data in 'perf record -e sched*'.
> - I'm assuming the three sched domains are SMT, MC and NUMA. Is that
> right? Do you have any powersavings balance or special sched domain
> flags enabled?
Yes, and the sched_mc_power_savings and sched_smt_power_savings were
both set. the NHM-EP domain like below:
CPU15 attaching sched-domain:
domain 0: span 7,15 level SIBLING
groups: 15 (cpu_power = 589) 7 (cpu_power = 589)
domain 1: span 1,3,5,7,9,11,13,15 level MC
groups: 7,15 (cpu_power = 1178) 1,9 (cpu_power = 1178) 3,11 (cpu_power = 1178) 5,13 (cpu_power = 1178)
domain 2: span 0-15 level NODE
groups: 1,3,5,7,9,11,13,15 (cpu_power = 4712) 0,2,4,6,8,10,12,14 (cpu_power = 4712)
> - Are you using group scheduling? If so, what does your setup look like?
I enabled the FAIR group default. But I have tried to disable it. the
problem is same. so, it isn't related to group.
>
> -Thanks,
> Nikhil
next prev parent reply other threads:[~2011-06-29 3:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-23 2:43 power increase issue on light load Alex,Shi
2011-06-23 9:02 ` Peter Zijlstra
2011-06-24 0:41 ` Alex,Shi
2011-06-28 0:02 ` Alex,Shi
2011-06-28 14:59 ` Peter Zijlstra
2011-06-28 17:13 ` Nikhil Rao
2011-06-29 2:30 ` Nikhil Rao
2011-06-29 3:22 ` Alex,Shi [this message]
2011-06-29 6:55 ` Alex,Shi
2011-06-30 0:26 ` Nikhil Rao
2011-06-30 8:38 ` Alex,Shi
2011-06-30 0:07 ` Nikhil Rao
2011-06-30 8:34 ` Alex,Shi
2011-07-01 5:44 ` Ming Lei
2011-07-01 18:00 ` Nikhil Rao
2011-07-01 23:51 ` Ming Lei
2011-07-04 0:45 ` Alex,Shi
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=1309317764.14604.92.camel@debian \
--to=alex.shi@intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=ncrao@google.com \
--cc=peterz@infradead.org \
--cc=shaohua.li@intel.com \
--cc=tim.c.chen@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.