On Tue, Jan 08, 2008 at 11:08:15PM +0530, Vaidyanathan Srinivasan wrote:Thanks for these experiments. sched_mc_power_savings is mainly for the reasonably long(which can be caught by periodic load balance) running light load(when number of tasks < number of logical cpus). This tunable will minimize the number of packages carrying load, enabling the other completely idle packages to go to the available deepest P and C states. Not really. Ideally sched_mc_power_savings re-distributes the load(in the scenarios mentioned above) to different logical cpus in the system, so as to minimize the busy packages in the system. ... In your setup, CPU0 and 3 are the core siblings? If so, this is probably expected. Previously there was some load distribution happening between packages. With sched_mc_power_savings, load is now getting distributed between cores in the same package. But on my systems, typically CPU0 and 2 are core siblings. I will let you confirm your system topology, before we come to conclusions. ... I would have expected similar results like in experiment-1. CPU3 data seems almost same with and without sched_mc_power_savings. Atleast the data is not significantly different as in other cases like CPU2 for ex. While we should see a no change or a simple redistribution(to minimize busy packages) in your experiments, for evaluating sched_mc_power_savings, we can also use some lightly loaded system (like kernel-compilation or specjbb with 2 threads on a DP with dual-core, for example and see how the load is distributed with and without MC power savings.) Similarly it will be interesting to see how this data varies with and without tickless. For some loads which can't be caught by periodic load balancer, we may not see any difference. But atleast we should not see any scheduling anomalies. thanks, suresh --
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Hiten Pandya | Re: up? (emacs docbook xml ide) |
| Andy Whitcroft | clam |
| Kamalesh Babulal | Re: 2.6.23-rc6-mm1 |
git: | |
| Stephen Hemminger | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
