[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?

> Cheers,
> 

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.