Re: [patch 28/34] Xen-pv_ops: Xen SMP guest support

Re: [patch 28/34] Xen-pv_ops: Xen SMP guest support

[Benjamin LaHaise]

On Tue, Mar 13, 2007 at 04:30:45PM -0700, Jeremy Fitzhardinge wrote:
> [ brcl, mingo: Would you mind having a close look at the code in
>   xen_exit_mm and drop_mm_ref? - Thanks ]

I see what you're doing here, and this comment seems to allude to the reasons 
behind it without spelling it out.

> +/*
> + * We aggressively remove defunct pgd from cr3. We execute unmap_vmas()
> + * *much* faster this way.
> + */

Are you switching mms in order to avoid all of the overhead associated with 
flushing an active mm during task exit?  If so, it makes much more sense to 
do this in the generic helper, as it should be a win on x86 and x86-64 
where switching to init_mm is relatively low cost given the support for 
global pages.  I'll run some tests on a couple of systems this evening and 
post the results.

		-ben
-- 
"Time is of no importance, Mr. President, only life is important."
Don't Email: <zyntrop@kvack.org>.

Re: [patch 28/34] Xen-pv_ops: Xen SMP guest support

[Jeremy Fitzhardinge]

Benjamin LaHaise wrote:
> Are you switching mms in order to avoid all of the overhead associated with 
> flushing an active mm during task exit?  If so, it makes much more sense to 
> do this in the generic helper, as it should be a win on x86 and x86-64 
> where switching to init_mm is relatively low cost given the support for 
> global pages.  I'll run some tests on a couple of systems this evening and 
> post the results.

Under Xen, the pagetables are mapped read-only to the guest, so all
pagetable updates need to go via the hypervisor.  If we switch to
init_mm and unpin (make all the pages RW) before pulling the pagetable
apart, then we can just traverse and modify the pagetable memory as
normal RW memory.  It avoids a heap of traps into the hypervisor.

    J

Re: [patch 28/34] Xen-pv_ops: Xen SMP guest support

[Zachary Amsden]

Benjamin LaHaise wrote:
>   
>> +/*
>> + * We aggressively remove defunct pgd from cr3. We execute unmap_vmas()
>> + * *much* faster this way.
>> + */
>>     
>
> Are you switching mms in order to avoid all of the overhead associated with 
> flushing an active mm during task exit?  If so, it makes much more sense to 
> do this in the generic helper, as it should be a win on x86 and x86-64 
> where switching to init_mm is relatively low cost given the support for 
> global pages.  I'll run some tests on a couple of systems this evening and 
> post the results.
>   

I tried this experiment on both x86 and x86-64 and I recall not seeing 
any effect.  The mmu_gather optimization does most of this already.

Zach

Re: [patch 10/34] Xen-pv_ops: Simplify smp_call_function*() by using common implementation

[Randy Dunlap]

On Tue, 13 Mar 2007 16:30:27 -0700 Jeremy Fitzhardinge wrote:

> smp_call_function and smp_call_function_single are almost complete
> duplicates of the same logic.  This patch combines them by
> implementing them in terms of the more general
> smp_call_function_mask().

The kernel-doc is still not quite correct.  Patch below applies
on top of this patch from Jeremy.
---

From: Randy Dunlap <randy.dunlap@oracle.com>

Clean up arch/i386/kernel/smp.c after the Xen pv_ops patches for
smp_call_function variants.

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 arch/i386/kernel/smp.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

--- linux-2621-rc3.orig/arch/i386/kernel/smp.c
+++ linux-2621-rc3/arch/i386/kernel/smp.c
@@ -517,14 +517,14 @@ static struct call_data_struct *call_dat
 
 
 /**
- * smp_call_function_mask(): Run a function on a set of other CPUs.
+ * smp_call_function_mask - Run a function on a set of other CPUs.
  * @mask: The set of cpus to run on.  Must not include the current cpu.
  * @func: The function to run. This must be fast and non-blocking.
  * @info: An arbitrary pointer to pass to the function.
  * @wait: If true, wait (atomically) until function has completed on other CPUs.
  *
  * Returns 0 on success, else a negative status code. Does not return until
- * remote CPUs are nearly ready to execute <<func>> or are or have finished.
+ * remote CPUs are nearly ready to execute func() or are or have finished.
  *
  * You must not call this function with disabled interrupts or from a
  * hardware interrupt handler or from a bottom half handler.
@@ -583,14 +583,14 @@ int smp_call_function_mask(cpumask_t mas
 }
 
 /**
- * smp_call_function(): Run a function on all other CPUs.
+ * smp_call_function - Run a function on all other CPUs.
  * @func: The function to run. This must be fast and non-blocking.
  * @info: An arbitrary pointer to pass to the function.
  * @nonatomic: currently unused.
  * @wait: If true, wait (atomically) until function has completed on other CPUs.
  *
  * Returns 0 on success, else a negative status code. Does not return until
- * remote CPUs are nearly ready to execute <<func>> or are or have executed.
+ * remote CPUs are nearly ready to execute func() or are or have executed.
  *
  * You must not call this function with disabled interrupts or from a
  * hardware interrupt handler or from a bottom half handler.
@@ -602,8 +602,9 @@ int smp_call_function(void (*func) (void
 }
 EXPORT_SYMBOL(smp_call_function);
 
-/*
+/**
  * smp_call_function_single - Run a function on another CPU
+ * @cpu: The target (destination) CPU number.
  * @func: The function to run. This must be fast and non-blocking.
  * @info: An arbitrary pointer to pass to the function.
  * @nonatomic: Currently unused.
@@ -611,7 +612,7 @@ EXPORT_SYMBOL(smp_call_function);
  *
  * Retrurns 0 on success, else a negative status code.
  *
- * Does not return until the remote CPU is nearly ready to execute <func>
+ * Does not return until the remote CPU is nearly ready to execute func()
  * or is or has executed.
  */
 int smp_call_function_single(int cpu, void (*func) (void *info), void *info,