On Fri, 2020-06-12 at 13:21 +0100, Julien Grall wrote:
> On 12/06/2020 12:33, Volodymyr Babchuk wrote:
> > On Fri, 2020-06-12 at 12:29 +0100, Julien Grall wrote:
> > > > Basically, this value holds time span between calls to
> > > > schedule(). This
> > > > variable gets zeroed out every time scheduler requests for time
> > > > adjustment value. So, it should not depend on total VM run
> > > > time.
> > > This is assuming that the scheduler will be called. With the NULL
> > > scheduler in place, there is a fair chance this may never be
> > > called.
> > > 
>
Yeah, this is a good point. I mean, I wouldn't be sure about "never",
as even there, we'd probably have softirqs, tasklets, etc... And I
still have to look at these patches in more details to figure out
properly whether they'd help for this.

But I'd say that, in general, we should depend of the frequency of the
scheduling events as few as possible. Therefore, using 64 bits from the
start would be preferrable IMO.

> > > So I think using a 64-bit value is likely safer.
> > 
Yep.

> > Well, I wanted to use 64-bit value in the first place. But I got
> > the
> > impression that atomic_t supports only 32-bit values. At least,
> > this is
> > what I'm seeing in atomic.h
> > 
> > Am I wrong?
> 
> There is no atomic64_t support in Xen yet. It shouldn't be very 
> difficult to add support for it if you require them.
> 
Cool! That would be much appreciated. :-D

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)