Re: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler

[Julien Grall <julien@xxxxxxx>]

On 12/06/2020 12:33, Volodymyr Babchuk wrote:
> On Fri, 2020-06-12 at 12:29 +0100, Julien Grall wrote:
> > On 12/06/2020 12:26, Volodymyr Babchuk wrote:
> > > Hi Jurgen,
> > >
> > > thanks for the review
> > >
> > > On Fri, 2020-06-12 at 06:36 +0200, Jürgen Groß wrote:
> > >
> > > > On 12.06.20 02:22, Volodymyr Babchuk wrote:
> > > [...]
> > >
> > > > > +void vcpu_end_irq_handler(void)
> > > > > +{
> > > > > +    int delta;
> > > > > +
> > > > > +    if (is_idle_vcpu(current))
> > > > > +        return;
> > > > > +
> > > > > +    ASSERT(current->irq_nesting);
> > > > > +
> > > > > +    if ( --current->irq_nesting )
> > > > > +        return;
> > > > > +
> > > > > +    /* We assume that irq handling time will not overflow int */
> > > > This assumption might not hold for long running VMs.
> > > 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.
> >
> > So I think using a 64-bit value is likely safer.
> 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.
Cheers,

--
Julien Grall