Re: [Xen-devel] [PATCH v2 02/10] xen: credit1: don't rate limit context switches in case of yields

[George Dunlap]

On 30/09/16 03:53, Dario Faggioli wrote:
> Rate limiting has been primarily introduced to avoid too
> heavy context switch rate due to interrupts, and, in
> general, asynchronous events.
> 
> If a vcpu "voluntarily" yields, we really should let it
> give up the cpu for a while.
> 
> In fact, it may be that it is yielding because it's about
> to start spinning, and there's few point in forcing a vcpu
> to spin for (potentially) the entire rate-limiting period.
> 
> Signed-off-by: Dario Faggioli 

Reviewed-by: George Dunlap 

> ---
> Cc: George Dunlap 
> Cc: Anshul Makkar 
> ---
> Changes from v1:
>  * move this patch up in the series, and remove the Credit2 bits, as suggested
>during review;
> ---
>  xen/common/sched_credit.c |   13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> index 4d84b5f..5700763 100644
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -1802,9 +1802,16 @@ csched_schedule(
>   *   cpu and steal it.
>   */
>  
> -/* If we have schedule rate limiting enabled, check to see
> - * how long we've run for. */
> -if ( !tasklet_work_scheduled
> +/*
> + * If we have schedule rate limiting enabled, check to see
> + * how long we've run for.
> + *
> + * If scurr is yielding, however, we don't let rate limiting kick in.
> + * In fact, it may be the case that scurr is about to spin, and there's
> + * no point forcing it to do so until rate limiting expires.
> + */
> +if ( !test_bit(CSCHED_FLAG_VCPU_YIELD, >flags)
> + && !tasklet_work_scheduled
>   && prv->ratelimit_us
>   && vcpu_runnable(current)
>   && !is_idle_vcpu(current)
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 02/10] xen: credit1: don't rate limit context switches in case of yields

[Dario Faggioli]

Rate limiting has been primarily introduced to avoid too
heavy context switch rate due to interrupts, and, in
general, asynchronous events.

If a vcpu "voluntarily" yields, we really should let it
give up the cpu for a while.

In fact, it may be that it is yielding because it's about
to start spinning, and there's few point in forcing a vcpu
to spin for (potentially) the entire rate-limiting period.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
Changes from v1:
 * move this patch up in the series, and remove the Credit2 bits, as suggested
   during review;
---
 xen/common/sched_credit.c |   13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 4d84b5f..5700763 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -1802,9 +1802,16 @@ csched_schedule(
  *   cpu and steal it.
  */
 
-/* If we have schedule rate limiting enabled, check to see
- * how long we've run for. */
-if ( !tasklet_work_scheduled
+/*
+ * If we have schedule rate limiting enabled, check to see
+ * how long we've run for.
+ *
+ * If scurr is yielding, however, we don't let rate limiting kick in.
+ * In fact, it may be the case that scurr is about to spin, and there's
+ * no point forcing it to do so until rate limiting expires.
+ */
+if ( !test_bit(CSCHED_FLAG_VCPU_YIELD, >flags)
+ && !tasklet_work_scheduled
  && prv->ratelimit_us
  && vcpu_runnable(current)
  && !is_idle_vcpu(current)


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel