[PATCH] xen: Don't disable the REP emulation optimizations for regular IO

[PATCH] xen: Don't disable the REP emulation optimizations for regular IO

[Razvan Cojocaru]

Currently REP emulations optimizations remain disabled even if
the emulation does not happen as a result of a vm_event reply
requestion emulation (i.e. even for regular IO). This patch takes
emulate_each_rep into account only if emulation has been requested
by a vm_event-capable application, and is a noticeable speed
optimization for monitored guests.

Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
---
 xen/arch/x86/hvm/emulate.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 082aa30..ddc8007 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -498,6 +498,7 @@ static int hvmemul_virtual_to_linear(
 {
     struct segment_register *reg;
     int okay;
+    unsigned long max_reps = 4096;
 
     if ( seg == x86_seg_none )
     {
@@ -506,16 +507,21 @@ static int hvmemul_virtual_to_linear(
     }
 
     /*
+     * If introspection has been enabled for this domain, and we're emulating
+     * becase a vm_reply asked us to (i.e. not doing regular IO) reps should
+     * be at most 1, since optimization might otherwise cause a single
+     * vm_event being triggered for repeated writes to a whole page.
+     */
+    if ( unlikely(current->domain->arch.mem_access_emulate_each_rep) &&
+         current->arch.vm_event->emulate_flags != 0 )
+       max_reps = 1;
+
+    /*
      * Clip repetitions to avoid overflow when multiplying by @bytes_per_rep.
      * The chosen maximum is very conservative but it's what we use in
      * hvmemul_linear_to_phys() so there is no point in using a larger value.
-     * If introspection has been enabled for this domain, *reps should be
-     * at most 1, since optimization might otherwise cause a single vm_event
-     * being triggered for repeated writes to a whole page.
      */
-    *reps = min_t(unsigned long, *reps,
-                  unlikely(current->domain->arch.mem_access_emulate_each_rep)
-                           ? 1 : 4096);
+    *reps = min_t(unsigned long, *reps, max_reps);
 
     reg = hvmemul_get_seg_reg(seg, hvmemul_ctxt);
 
-- 
1.9.1


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

Re: [PATCH] xen: Don't disable the REP emulation optimizations for regular IO

[Jan Beulich]

>>> On 10.03.16 at 11:07, <rcojocaru@bitdefender.com> wrote:
> Currently REP emulations optimizations remain disabled even if
> the emulation does not happen as a result of a vm_event reply
> requestion emulation (i.e. even for regular IO). This patch takes
> emulate_each_rep into account only if emulation has been requested
> by a vm_event-capable application, and is a noticeable speed
> optimization for monitored guests.
> 
> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>

Looks reasonable, but this being an event specific change I'm
making my ack to this dependent on Tamas'es consent.

Jan

> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -498,6 +498,7 @@ static int hvmemul_virtual_to_linear(
>  {
>      struct segment_register *reg;
>      int okay;
> +    unsigned long max_reps = 4096;
>  
>      if ( seg == x86_seg_none )
>      {
> @@ -506,16 +507,21 @@ static int hvmemul_virtual_to_linear(
>      }
>  
>      /*
> +     * If introspection has been enabled for this domain, and we're emulating
> +     * becase a vm_reply asked us to (i.e. not doing regular IO) reps should
> +     * be at most 1, since optimization might otherwise cause a single
> +     * vm_event being triggered for repeated writes to a whole page.
> +     */
> +    if ( unlikely(current->domain->arch.mem_access_emulate_each_rep) &&
> +         current->arch.vm_event->emulate_flags != 0 )
> +       max_reps = 1;
> +
> +    /*
>       * Clip repetitions to avoid overflow when multiplying by @bytes_per_rep.
>       * The chosen maximum is very conservative but it's what we use in
>       * hvmemul_linear_to_phys() so there is no point in using a larger value.
> -     * If introspection has been enabled for this domain, *reps should be
> -     * at most 1, since optimization might otherwise cause a single vm_event
> -     * being triggered for repeated writes to a whole page.
>       */
> -    *reps = min_t(unsigned long, *reps,
> -                  unlikely(current->domain->arch.mem_access_emulate_each_rep)
> -                           ? 1 : 4096);
> +    *reps = min_t(unsigned long, *reps, max_reps);
>  
>      reg = hvmemul_get_seg_reg(seg, hvmemul_ctxt);
>  
> -- 
> 1.9.1




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

Re: [PATCH] xen: Don't disable the REP emulation optimizations for regular IO

[Andrew Cooper]

On 10/03/16 10:07, Razvan Cojocaru wrote:
> Currently REP emulations optimizations remain disabled even if
> the emulation does not happen as a result of a vm_event reply
> requestion emulation (i.e. even for regular IO). This patch takes
> emulate_each_rep into account only if emulation has been requested
> by a vm_event-capable application, and is a noticeable speed
> optimization for monitored guests.
>
> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

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

Re: [PATCH] xen: Don't disable the REP emulation optimizations for regular IO

[Tamas K Lengyel]

[-- Attachment #1.1: Type: text/plain, Size: 2499 bytes --]

On Mar 10, 2016 11:09, "Razvan Cojocaru" <rcojocaru@bitdefender.com> wrote:
>
> Currently REP emulations optimizations remain disabled even if
> the emulation does not happen as a result of a vm_event reply
> requestion emulation (i.e. even for regular IO). This patch takes
> emulate_each_rep into account only if emulation has been requested
> by a vm_event-capable application, and is a noticeable speed
> optimization for monitored guests.
>
> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>

Reviewed-by: Tamas K Lengyel <tamas@tklengyel.com>

> ---
>  xen/arch/x86/hvm/emulate.c | 18 ++++++++++++------
>  1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index 082aa30..ddc8007 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -498,6 +498,7 @@ static int hvmemul_virtual_to_linear(
>  {
>      struct segment_register *reg;
>      int okay;
> +    unsigned long max_reps = 4096;
>
>      if ( seg == x86_seg_none )
>      {
> @@ -506,16 +507,21 @@ static int hvmemul_virtual_to_linear(
>      }
>
>      /*
> +     * If introspection has been enabled for this domain, and we're
emulating
> +     * becase a vm_reply asked us to (i.e. not doing regular IO) reps
should
> +     * be at most 1, since optimization might otherwise cause a single
> +     * vm_event being triggered for repeated writes to a whole page.
> +     */
> +    if ( unlikely(current->domain->arch.mem_access_emulate_each_rep) &&
> +         current->arch.vm_event->emulate_flags != 0 )
> +       max_reps = 1;
> +
> +    /*
>       * Clip repetitions to avoid overflow when multiplying by
@bytes_per_rep.
>       * The chosen maximum is very conservative but it's what we use in
>       * hvmemul_linear_to_phys() so there is no point in using a larger
value.
> -     * If introspection has been enabled for this domain, *reps should be
> -     * at most 1, since optimization might otherwise cause a single
vm_event
> -     * being triggered for repeated writes to a whole page.
>       */
> -    *reps = min_t(unsigned long, *reps,
> -
unlikely(current->domain->arch.mem_access_emulate_each_rep)
> -                           ? 1 : 4096);
> +    *reps = min_t(unsigned long, *reps, max_reps);
>
>      reg = hvmemul_get_seg_reg(seg, hvmemul_ctxt);
>
> --
> 1.9.1
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

[-- Attachment #1.2: Type: text/html, Size: 3452 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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