| Message ID | 147520401251.22544.7327169776043168083.stgit@Solace.fritz.box (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 <dario.faggioli@citrix.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com> > --- > Cc: George Dunlap <george.dunlap@eu.citrix.com> > Cc: Anshul Makkar <anshul.makkar@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) >
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)
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.faggioli@citrix.com> --- Cc: George Dunlap <george.dunlap@eu.citrix.com> Cc: Anshul Makkar <anshul.makkar@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(-)