Re: Make kstat_incr_irqs_this_cpu() called when an irq is actuallybeing handled

[Ning Jiang]

 2012/6/1 Ning Jiang <ning.n.jiang@xxxxxxxxx>:
> 2012/6/1 Thomas Gleixner <tglx@xxxxxxxxxxxxx>:
>> On Thu, 31 May 2012, Ning Jiang wrote:
>>> kstat_incr_irqs_this_cpu() is supposed to record the irq number
>>> that is actually taken by a certain cpu. But it failed to do so
>>> in its current form.
>>
>> It exactly counts the number of interrupts which are delivered to and
>> handled by a CPU. That includes interrupts which are delivered in a
>> state where the device handler cannot be called. And this is on
>> purpose. We want to see the real number of interruptions not the
>> number of calls to a device handler.
>>
>>> For level irq, if its disabled or no action available, we'll skip
>>> irq handling. When it is enabled later, the irq will be retriggered
>>> and kstat_incr_irqs_this_cpu() will be counted twice for this
>>> single irq.
>>
>> This counts the number of interrupts arrived at the CPU and therefor
>> it counts TWO in this situation. The CPU is interrupted twice, not
>> once.
>>
>
> I've got your point. For level irq, no problem. But how do you account
> for edge irq in my comments?
>
> For edge irq, we'll not have the same problem as level irq because
> kstat_incr_irqs_this_cpu() is placed after status checking for
> disable or no action. But it has its own problem. Suppose a second
> irq happens when the first is being handled, it will mark itself
> pending and quit, then it will be handled in the same loop after the
> first one has been handled. Thus kstat_incr_irqs_this_cpu() will
> only be counted once for two irqs.


I've made a another patch based on your conception of irq accounting.
It fixes the
corner case in which there comes up a second irq when the first is
still in progress,
we'll increment the irq count before we quit.