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 <dario.faggi...@citrix.com>
---
Cc: George Dunlap <george.dun...@eu.citrix.com>
Cc: Anshul Makkar <anshul.mak...@citrix.com>
---
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, &scurr->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
