Re: [PATCH v3] sched: Don't try to catch up excess steal time.

From: Steven Rostedt
Date: Mon Nov 18 2024 - 19:17:56 EST


On Tue, 19 Nov 2024 09:10:41 +0900
Joel Fernandes <joelaf@xxxxxxxxxx> wrote:

> > > +++ b/kernel/sched/core.c
> > > @@ -766,13 +766,15 @@ static void update_rq_clock_task(struct rq *rq, s64 delta)
> > > #endif
> > > #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
> > > if (static_key_false((&paravirt_steal_rq_enabled))) {
> > > - steal = paravirt_steal_clock(cpu_of(rq));
> > > + u64 prev_steal;
> > > +
> > > + steal = prev_steal = paravirt_steal_clock(cpu_of(rq));
> > > steal -= rq->prev_steal_time_rq;
> > >
> > > if (unlikely(steal > delta))
> > > steal = delta;
> >
> > So is the problem just the above if statement? That is, delta is already
> > calculated, but if we get interrupted by the host before steal is
> > calculated and the time then becomes greater than delta, the time
> > difference between delta and steal gets pushed off to the next task, right?
>
> Pretty much.. the steal being capped to delta means the rest of the
> steal is pushed off to the future. Instead he discards the remaining
> steal after this patch.

Thanks for confirming. I just wanted to make sure I understand as the
initial change log went into a lot of detail where I sorta got lost ;-)

-- Steve