On Fri, 2020-06-12 at 06:51 +0200, Jürgen Groß wrote:
> On 12.06.20 02:22, Volodymyr Babchuk wrote:
> > Now we can make corrections for scheduling unit run time, based on
> > data gathered in previous patches. This includes time spent in IRQ
> > handlers and time spent for hypervisor housekeeping tasks. Those time
> > spans needs to be deduced from a total run time.
> >
> > This patch adds sched_get_time_correction() function which returns
> > time correction value. This value should be subtracted by a scheduler
> > implementation from a total vCPU/shced_unit run time.
> >
> > TODO: Make the corresponding changes to all other schedulers.
> >
> > Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com>
> > ---
> > xen/common/sched/core.c | 23 +++++++++++++++++++++++
> > xen/common/sched/credit2.c | 2 +-
> > xen/common/sched/private.h | 10 ++++++++++
> > 3 files changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
> > index d597811fef..a7294ff5c3 100644
> > --- a/xen/common/sched/core.c
> > +++ b/xen/common/sched/core.c
> > @@ -974,6 +974,29 @@ void vcpu_end_hyp_task(struct vcpu *v)
> > #ifndef NDEBUG
> > v->in_hyp_task = false;
> > #endif
> > +
> > +s_time_t sched_get_time_correction(struct sched_unit *u)
> > +{
> > + unsigned long flags;
> > + int irq, hyp;
>
> Using "irq" for a time value is misleading IMO.
Yes, you are right. I'll rename this variables to irq_time and
hyp_time.
> > +
> > + while ( true )
> > + {
> > + irq = atomic_read(&u->irq_time);
> > + if ( likely( irq == atomic_cmpxchg(&u->irq_time, irq, 0)) )
> > + break;
> > + }
>
> Just use atomic_xchg()?
Thanks. I somehow missed this macro.
> > +
> > + while ( true )
> > + {
> > + hyp = atomic_read(&u->hyp_time);
> > + if ( likely( hyp == atomic_cmpxchg(&u->hyp_time, hyp, 0)) )
> > + break;
> > + }
> > +
> > + return irq + hyp;
>
> Ah, I didn't look into this patch until now.
>
> You can replace my comments about overflow of an int for patches 1 and 2
> with:
>
> Please modify the comment about not overflowing hinting to the value
> being reset when making scheduling decisions.
Will do.
> And this (of course) needs to be handled in all other schedulers, too.
>
Yes, the plan is to call this function in all schedulers. I skipped
this in RFC, because I wanted to discuss the general approch. I'll add
support for all other schedulers in the next version.
