Xen devel - Mar 2010 - "monitor"-ed address and IPI reduction

What is the point of specifying "current" as the address to monitor?
The
memory location of interest really is irq_stat[cpu].__softirq_pending,
and if that was used it would then also be possible to actually avoid
sending IPIs when monitor/mwait are in use, as is being done on Linux.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Jan Beulich wrote:
> What is the point of specifying "current" as the address to
monitor?
You provide a good point. The original purpose to monitor "current" is
to avoid accidentally wakeup while relying on ipi for waking up mechanism.
> The memory location of interest really is
> irq_stat[cpu].__softirq_pending, and if that was used it would then
> also be possible to actually avoid sending IPIs when monitor/mwait
> are in use, as is being done on Linux. 
I agree that we can have a try on this. Waking up cpu by mem write should be
more efficient for monitor/mwait case.

Jimmy
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Wei, Gang wrote:
> Jan Beulich wrote:
>> What is the point of specifying "current" as the address to
monitor?
> 
> You provide a good point. The original purpose to monitor
"current"
> is to avoid accidentally wakeup while relying on ipi for waking up
> mechanism.  
> 
>> The memory location of interest really is
>> irq_stat[cpu].__softirq_pending, and if that was used it would then
>> also be possible to actually avoid sending IPIs when monitor/mwait
>> are in use, as is being done on Linux.
> 
> I agree that we can have a try on this. Waking up cpu by mem write
> should be more efficient for monitor/mwait case. 
Here is a patch to monitor "sortirq_pending" instead of
"current". The IPI reduction part may be a bit complex, can we hold it
for post-4.0?

Jimmy
---------------------------
CPUIDLE: monitor "sortirq_pending" instead of "current"

Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Wei Gang <gang.wei@intel.com>

diff -r 132ac04cbdba xen/arch/x86/acpi/cpu_idle.c
--- a/xen/arch/x86/acpi/cpu_idle.c	Tue Mar 09 18:18:19 2010 +0000
+++ b/xen/arch/x86/acpi/cpu_idle.c	Wed Mar 10 11:23:14 2010 +0800
@@ -142,9 +142,13 @@ static void acpi_safe_halt(void)
 
 static void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
 {
-    __monitor((void *)current, 0, 0);
+    int cpu = smp_processor_id();
+
+    __monitor((void *)&softirq_pending(cpu), 0, 0);
+
     smp_mb();
-    __mwait(eax, ecx);
+    if ( !softirq_pending(cpu) )
+        __mwait(eax, ecx);
 }
 
 static void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx *cx)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/03/2010 05:09, "Wei, Gang" <gang.wei@intel.com> wrote:
>> I agree that we can have a try on this. Waking up cpu by mem write
>> should be more efficient for monitor/mwait case.
> 
> Here is a patch to monitor "sortirq_pending" instead of
"current". The IPI
> reduction part may be a bit complex, can we hold it for post-4.0?
This whole thing is for post 4.0 now.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser wrote:
> On 10/03/2010 05:09, "Wei, Gang" <gang.wei@intel.com>
wrote:
> 
>>> I agree that we can have a try on this. Waking up cpu by mem write
>>> should be more efficient for monitor/mwait case.
>> 
>> Here is a patch to monitor "sortirq_pending" instead of
"current".
>> The IPI reduction part may be a bit complex, can we hold it for
>> post-4.0? 
> 
> This whole thing is for post 4.0 now.
That''s fine.

Jimmy
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel