From 9fdd2f3c9ccb5b51c4610eb535d7ae8bc8e27c8a Mon Sep 17 00:00:00 2001 From: Dario Faggioli Date: Fri, 30 Sep 2016 04:53:32 +0200 Subject: [PATCH] xen: credit1: don't rate limit context switches in case of yields 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 --- 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 4d84b5fb8a..5700763ccd 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) -- 2.30.2