|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-changelog] [xen master] x86/idle: reduce contention on ACPI register accesses
commit 178fd279dc138243b514b4ecd48509e4bf5d1ede
Author: Jan Beulich <jbeulich@xxxxxxxx>
AuthorDate: Mon Nov 11 11:01:04 2013 +0100
Commit: Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Mon Nov 11 11:01:04 2013 +0100
x86/idle: reduce contention on ACPI register accesses
Other than when they're located in I/O port space, accessing them when
in MMIO space (currently) implies usage of some sort of global lock: In
-unstable this would be due to the use of vmap(), is older trees the
necessary locking was introduced by 2ee9cbf9 ("ACPI: fix
acpi_os_map_memory()"). This contention was observed to result in Dom0
kernel soft lockups during the loading of the ACPI processor driver
there on systems with very many CPU cores.
There are a couple of things being done for this:
- re-order elements of an if() condition so that the register access
only happens when we really need it
- turn off arbitration disabling only when the first CPU leaves C3
(paralleling how arbitration disabling gets turned on)
- only set the (global) bus master reload flag once (when the first
target CPU gets processed)
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Keir Fraser <keir@xxxxxxx>
---
xen/arch/x86/acpi/cpu_idle.c | 33 ++++++++++++++++++---------------
1 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 870fab8..9313285 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -439,8 +439,8 @@ static void acpi_processor_idle(void)
(next_state = cpuidle_current_governor->select(power)) > 0 )
{
cx = &power->states[next_state];
- if ( power->flags.bm_check && acpi_idle_bm_check()
- && cx->type == ACPI_STATE_C3 )
+ if ( cx->type == ACPI_STATE_C3 && power->flags.bm_check &&
+ acpi_idle_bm_check() )
cx = power->safe_state;
if ( cx->idx > max_cstate )
cx = &power->states[max_cstate];
@@ -563,8 +563,8 @@ static void acpi_processor_idle(void)
{
/* Enable bus master arbitration */
spin_lock(&c3_cpu_status.lock);
- acpi_set_register(ACPI_BITREG_ARB_DISABLE, 0);
- c3_cpu_status.count--;
+ if ( c3_cpu_status.count-- == num_online_cpus() )
+ acpi_set_register(ACPI_BITREG_ARB_DISABLE, 0);
spin_unlock(&c3_cpu_status.lock);
}
@@ -821,12 +821,10 @@ static int check_cx(struct acpi_processor_power *power,
xen_processor_cx_t *cx)
return -EINVAL;
/* All the logic here assumes flags.bm_check is same across all CPUs */
- if ( bm_check_flag == -1 )
+ if ( bm_check_flag < 0 )
{
/* Determine whether bm_check is needed based on CPU */
acpi_processor_power_init_bm_check(&(power->flags));
- bm_check_flag = power->flags.bm_check;
- bm_control_flag = power->flags.bm_control;
}
else
{
@@ -853,14 +851,13 @@ static int check_cx(struct acpi_processor_power *power,
xen_processor_cx_t *cx)
}
}
/*
- * On older chipsets, BM_RLD needs to be set
- * in order for Bus Master activity to wake the
- * system from C3. Newer chipsets handle DMA
- * during C3 automatically and BM_RLD is a NOP.
- * In either case, the proper way to
- * handle BM_RLD is to set it and leave it set.
+ * On older chipsets, BM_RLD needs to be set in order for Bus
+ * Master activity to wake the system from C3, hence
+ * acpi_set_register() is always being called once below. Newer
+ * chipsets handle DMA during C3 automatically and BM_RLD is a
+ * NOP. In either case, the proper way to handle BM_RLD is to
+ * set it and leave it set.
*/
- acpi_set_register(ACPI_BITREG_BUS_MASTER_RLD, 1);
}
else
{
@@ -875,7 +872,13 @@ static int check_cx(struct acpi_processor_power *power,
xen_processor_cx_t *cx)
" for C3 to be enabled on SMP systems\n"));
return -EINVAL;
}
- acpi_set_register(ACPI_BITREG_BUS_MASTER_RLD, 0);
+ }
+
+ if ( bm_check_flag < 0 )
+ {
+ bm_check_flag = power->flags.bm_check;
+ bm_control_flag = power->flags.bm_control;
+ acpi_set_register(ACPI_BITREG_BUS_MASTER_RLD, bm_check_flag);
}
break;
--
generated by git-patchbot for /home/xen/git/xen.git#master
_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |