| 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
| ||
|
Date: Thu, 02 Apr 2009 18:08:24 +0530
From: Gautham R Shenoy <ego@...ibm.com>
To: "Ingo Molnar" <mingo@...e.hu>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org,
Suresh Siddha <suresh.b.siddha@...el.com>,
"Balbir Singh" <balbir@...ibm.com>,
Andi Kleen <andi@...stfloor.org>
Subject: [PATCH v2 0/2] sched: Nominate a power-efficient ILB.
Hi,
This patchset improves the idle-load balancer nomination logic, by taking
into consideration the system topology into consideration.
An idle-load balancer is an idle-cpu which does not turn off it's sched_ticks
and performs load-balancing on behalf of the other idle CPUs. Currently,
this idle load balancer is nominated as the first_cpu(nohz.cpu_mask)
The drawback of the current method is that the CPU numbering in the
cores/packages need not necessarily be sequential. For example, on a
two-socket, Quad core system, the CPU numbering can be as follows:
|-------------------------------| |-------------------------------|
| | | | | |
| 0 | 2 | | 1 | 3 |
|-------------------------------| |-------------------------------|
| | | | | |
| 4 | 6 | | 5 | 7 |
|-------------------------------| |-------------------------------|
Now, the other power-savings settings such as the sched_mc/smt_power_savings
and the power-aware IRQ balancer try to balance tasks/IRQs by taking
the system topology into consideration, with the intention of keeping
as many "power-domains" (cores/packages) in the low-power state.
The current idle-load-balancer nomination does not necessarily align towards
this policy. For eg, we could be having tasks and interrupts largely running
on the first package with the intention of keeping the second package idle.
Hence, CPU 0 may be busy. The first_cpu in the nohz.cpu_mask happens to be CPU1,
which in-turn becomes nominated as the idle-load balancer. CPU1 being from
the 2nd package, would in turn prevent the 2nd package from going into a
deeper sleep state.
Instead the role of the idle-load balancer could have been assumed by an
idle CPU from the first package, thereby helping the second package go
completely idle.
This patchset has been tested with 2.6.29-tip-master on a Two-Socket
Quad core system with the topology as mentioned above.
|----------------------------------------------------------------------------|
| With Patchset + sched_mc_power_savings = 1 |
|----------------------------------------------------------------------------|
|make -j2 options| time taken | LOC timer interrupts | LOC timer interrupts|
| | | on Package 0 | on Package 1 |
|----------------------------------------------------------------------------|
|taskset -c 0,2 | | CPU0 | CPU2 | CPU1 | CPU3 |
| | 221.675s | 55421 | 55530 | 587 | 579 |
| | |----------------------------------------------|
| | | CPU4 | CPU6 | CPU5 | CPU7 |
| | | 54335 | 642 | 734 | 533 |
|----------------------------------------------------------------------------|
|taskset -c 1,3 | | CPU0 | CPU2 | CPU1 | CPU3 |
| | 221.806s | 1241 | 553 | 55566 | 55555 |
| | |----------------------------------------------|
| | | CPU4 | CPU6 | CPU5 | CPU7 |
| | | 567 | 632 | 54332 | 561 |
|----------------------------------------------------------------------------|
We see here that the idle load balancer is chosen from the package which is
busy. In the first case, it's CPU4 and in the second case it's CPU5.
|----------------------------------------------------------------------------|
| Without Patchset + sched_mc_power_savings = 1 |
|----------------------------------------------------------------------------|
|make -j2 options| time taken | LOC timer interrupts | LOC timer interrupts|
| | | on Package 0 | on Package 1 |
|----------------------------------------------------------------------------|
|taskset -c 0,2 | | CPU0 | CPU2 | CPU1 | CPU3 |
| | 221.727s | 55100 | 55134 | 55134 | 14591 |
| | |----------------------------------------------|
| | | CPU4 | CPU6 | CPU5 | CPU7 |
| | | 1590 | 856 | 613 | 598 |
|----------------------------------------------------------------------------|
|taskset -c 1,3 | | CPU0 | CPU2 | CPU1 | CPU3 |
| | 221.500s | 43444 | 12918 | 54766 | 55170 |
| | |----------------------------------------------|
| | | CPU4 | CPU6 | CPU5 | CPU7 |
| | | 653 | 777 | 1008 | 585 |
|----------------------------------------------------------------------------|
Here, we see that the idle load balancer is chosen from the other package,
despite choosing sched_mc_power_savings = 1. In the first case, we have
CPU1 and CPU3 sharing the responsibility among themselves. In the second case,
it's CPU0 and CPU2, which assume that role.
Thoughts ?
---
Gautham R Shenoy (2):
sched: Nominate a power-efficient ilb in select_nohz_balancer()
sched: Nominate idle load balancer from a semi-idle package.
kernel/sched.c | 127 ++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 117 insertions(+), 10 deletions(-)
--
Thanks and Regards
gautham.
--
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/
Powered by blists - more mailing lists