[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1908280104330.1939@nanos.tec.linutronix.de>
Date: Wed, 28 Aug 2019 01:09:44 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Ming Lei <ming.lei@...hat.com>
cc: linux-kernel@...r.kernel.org, Long Li <longli@...rosoft.com>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Keith Busch <keith.busch@...el.com>, Jens Axboe <axboe@...com>,
Christoph Hellwig <hch@....de>,
Sagi Grimberg <sagi@...mberg.me>,
John Garry <john.garry@...wei.com>,
Hannes Reinecke <hare@...e.com>,
linux-nvme@...ts.infradead.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism
On Wed, 28 Aug 2019, Ming Lei wrote:
> On Tue, Aug 27, 2019 at 04:42:02PM +0200, Thomas Gleixner wrote:
> > On Tue, 27 Aug 2019, Ming Lei wrote:
> > > +
> > > + int cpu = raw_smp_processor_id();
> > > + struct irq_interval *inter = per_cpu_ptr(&avg_irq_interval, cpu);
> > > + u64 delta = sched_clock_cpu(cpu) - inter->last_irq_end;
> >
> > Why are you doing that raw_smp_processor_id() dance? The call site has
> > interrupts and preemption disabled.
>
> OK, will change to __smp_processor_id().
You do not need smp_processor_id() as all.
> > Also how is that supposed to work when sched_clock is jiffies based?
>
> Good catch, looks ktime_get_ns() is needed.
And what is ktime_get_ns() returning when the only available clocksource is
jiffies?
> >
> > > + inter->avg = (inter->avg * IRQ_INTERVAL_EWMA_PREV_FACTOR +
> > > + delta * IRQ_INTERVAL_EWMA_CURR_FACTOR) /
> > > + IRQ_INTERVAL_EWMA_WEIGHT;
> >
> > We definitely are not going to have a 64bit multiplication and division on
> > every interrupt. Asided of that this breaks 32bit builds all over the place.
>
> I will convert the above into add/subtract/shift only.
No. Talk to Daniel. There is not going to be yet another ad hoc thingy just
to make block happy.
And aside of that why does block not have a "NAPI" mode which was
explicitely designed to avoid all that?
Thanks,
tglx
Powered by blists - more mailing lists