[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.20.1703231542500.2304@knanqh.ubzr>
Date: Thu, 23 Mar 2017 15:50:01 -0400 (EDT)
From: Nicolas Pitre <nicolas.pitre@...aro.org>
To: Thomas Gleixner <tglx@...utronix.de>
cc: Daniel Lezcano <daniel.lezcano@...aro.org>,
linux-kernel@...r.kernel.org, peterz@...radead.org,
rafael@...nel.org, vincent.guittot@...aro.org
Subject: Re: [PATCH V8 2/3] irq: Track the interrupt timings
On Thu, 23 Mar 2017, Thomas Gleixner wrote:
> On Thu, 23 Mar 2017, Nicolas Pitre wrote:
>
> > On Thu, 23 Mar 2017, Daniel Lezcano wrote:
> >
> > > +#define IRQ_TIMINGS_SHIFT 5
> > > +#define IRQ_TIMINGS_SIZE (1 << IRQ_TIMINGS_SHIFT)
> > > +#define IRQ_TIMINGS_MASK (IRQ_TIMINGS_SIZE - 1)
> > > +
> > > +struct irq_timing {
> > > + u32 irq;
> > > + u64 ts;
> > > +};
> > > +
> > > +struct irq_timings {
> > > + struct irq_timing values[IRQ_TIMINGS_SIZE]; /* our circular buffer */
> >
> > This is not very space efficient because of alignment restrictions from
> > the u64 in struct irq_timing. 25% of the memory is wasted.
> >
> > You could consider having two arrays instead:
> >
> > u32 irq_values[IRQ_TIMINGS_SIZE];
> > u64 ts_values[IRQ_TIMINGS_SIZE];
>
> For the penalty of dirtying two cachelines instead of one.
Well...
Is there a need for 64 bits of relative time stamps?
And 32 bits of IRQ number?
I'd say that 48 bit time stamp and 16 bit IRQ number is way sufficient.
Who cares if we mispredict an IRQ after 78 hours of idle time?
Hence:
u64 value = (ts << 16) | irq;
Nicolas
Powered by blists - more mailing lists