[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] acpi: do not flush cache if cx->type != ACPI_STATE_C3



This should not be enough. No need to check bm when going to C2.
How about the following patch:
diff -r d35a117afa2f xen/arch/x86/acpi/cpu_idle.c
--- a/xen/arch/x86/acpi/cpu_idle.c      Tue Mar 27 15:25:07 2012 +0200
+++ b/xen/arch/x86/acpi/cpu_idle.c      Fri Apr 13 10:10:31 2012 +0800
@@ -493,7 +493,8 @@ static void acpi_processor_idle(void)
          * not set. In that case we cannot do much, we enter C3
          * without doing anything.
          */
-        if ( power->flags.bm_check && power->flags.bm_control )
+        if ( (cx->type == ACPI_STATE_C3) && power->flags.bm_check
+                                          && power->flags.bm_control )
         {
             spin_lock(&c3_cpu_status.lock);
             if ( ++c3_cpu_status.count == num_online_cpus() )
@@ -509,13 +510,14 @@ static void acpi_processor_idle(void)
         else if ( !power->flags.bm_check )
         {
             /* SMP with no shared cache... Invalidate cache  */
-            ACPI_FLUSH_CPU_CACHE();
+            if ( cx->type == ACPI_STATE_C3 )
+                ACPI_FLUSH_CPU_CACHE();
         }
-
         /* Invoke C3 */
         acpi_idle_do_entry(cx);

-        if ( power->flags.bm_check && power->flags.bm_control )
+        if ( (cx->type == ACPI_STATE_C3) && power->flags.bm_check
+                                        && power->flags.bm_control )
         {
             /* Enable bus master arbitration */
             spin_lock(&c3_cpu_status.lock);

best regards
yang


> -----Original Message-----
> From: Wei Wang [mailto:wei.wang2@xxxxxxx]
> Sent: Thursday, April 12, 2012 9:11 PM
> To: Jan Beulich; Keir Fraser
> Cc: Zhang, Yang Z; xen-devel@xxxxxxxxxxxxxxxxxxx; Andre Przywara; Ostrovsky,
> Boris; Wei Huang
> Subject: [PATCH] acpi: do not flush cache if cx->type != ACPI_STATE_C3
> 
> Hi Jan,
> This is a revised fix from my last post[1]. We found that the performance
> issue[2] is actually caused by an unnecessary cache flush when fall-through
> happens. According to acpi spec, c2 has cache consistency, we don't need
> cache flush if cx->type != ACPI_STATE_C3.
> This fix improves performance of some OEM systems significantly. I would
> suggest to back port it to 4.1, 4.0 and even 3.4.
> 
> Thanks,
> We
> 
> [1]
> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00395.html
> [2]
> http://forums.citrix.com/thread.jspa?threadID=297461&tstart=0&start=0
> 
> # HG changeset patch
> # Parent 6efb9f934bfb4c46af375612fb01e65d15518380
> # User Wei Wang <wei.wang2@xxxxxxx>
> acpi: do not flush cache if cx->type != ACPI_STATE_C3
> 
> Signed-off-by: Wei Wang <wei.wang2@xxxxxxx>
> 
> diff -r 6efb9f934bfb -r 85775fd04cf4 xen/arch/x86/acpi/cpu_idle.c
> --- a/xen/arch/x86/acpi/cpu_idle.c      Thu Apr 05 11:24:26 2012 +0100
> +++ b/xen/arch/x86/acpi/cpu_idle.c      Thu Apr 12 14:15:09 2012 +0200
> @@ -509,7 +509,8 @@ static void acpi_processor_idle(void)
>           else if ( !power->flags.bm_check )
>           {
>               /* SMP with no shared cache... Invalidate cache  */
> -            ACPI_FLUSH_CPU_CACHE();
> +            if ( cx->type == ACPI_STATE_C3 )
> +                ACPI_FLUSH_CPU_CACHE();
>           }
> 
>           /* Invoke C3 */


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.