From: Thomas Gleixner <tglx@linutronix.de>
To: l00520965 <liuchao173@huawei.com>
Cc: linfeilong@huawei.com, hushiyuan@huawei.com,
LiuChao <liuchao173@huawei.com>,
linux-kernel@vger.kernel.org,
PJ Waskiewicz <peter.waskiewicz.jr@intel.com>,
Neil Horman <nhorman@tuxdriver.com>
Subject: Re: [RFC] irq: Skip printing irq when desc->action is null even if any_count is not zero
Date: Wed, 22 Jan 2020 13:42:48 +0100 [thread overview]
Message-ID: <87k15jek6v.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200121130959.22589-1-liuchao173@huawei.com>
Chao,
l00520965 <liuchao173@huawei.com> writes:
> When desc->action is empty, there is no need to print out the irq and its'
> count in each cpu. The desc is not alloced in request_irq or freed in
> free_irq.
request/free_irq() never allocate/free irq descriptors.
> So some PCI devices, such as rtl8139, uses request_irq and free_irq,
All PCI devices use some variant of request_irq()/free_irq(). The
interrupt descriptors are allocated by the underlying PCI
machinery. They are only allocated/freed when the device driver is
loaded/removed.
And this property exists for _ALL_ interrupts independent of PCI.
> which only modify the action of desc. So /proc/interrupts could be
> like this:
I think you want to explain:
If an interrupt is released via free_irq() without removing the
underlying irq descriptor, the interrupt count of the irq descriptor
is not reset. /proc/interrupt shows such interrupts with an empty
action handler name:
> CPU0 CPU1
> 38: 46 0 GICv3 36 Level ehci_hcd:usb1
> 39: 66 0 GICv3 37 Level
irqbalance fails to detect that this interrupt is not longer in use
and parses the last word in the line 'Level' as the action handler
name.
> Irqbalance gets the list of interrupts according to /proc/interrupts. In
> this case, irqbalance does not remove the interrupt from the balance list,
> and the last string in this line,which is Level, is used as irq_name.
Right, this is historic behaviour and I don't know how irqbalance dealt
with that in the past 20+ years. At least I haven't seen any complaints.
I'm not opposed to suppress the output, but I really want the opinion of
the irqbalance maintainers on that.
> Or we can clear desc->kstat_irqs in each cpu in free_irq when
> desc->action is null?
No, we can't. The historic behaviour is that the total interrupt count
for a device is maintained independent of the number of
request/free_irq() pairs.
> Signed-off-by: LiuChao <liuchao173@huawei.com>
> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
I really can't remember that I have reviewed this patch already. Please
don't add tags which claim that some one has reviewed or acked your
patch unless you really got that Reviewed-by or Acked-by from that
person.
Thanks,
tglx
next prev parent reply other threads:[~2020-01-22 12:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-21 13:09 [RFC] irq: Skip printing irq when desc->action is null even if any_count is not zero l00520965
2020-01-22 12:42 ` Thomas Gleixner [this message]
2020-01-22 19:28 ` Neil Horman
2020-01-23 2:06 ` 答复: " liuchao (CR)
2020-01-23 12:34 ` Thomas Gleixner
2020-01-23 21:40 ` Neil Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k15jek6v.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=hushiyuan@huawei.com \
--cc=linfeilong@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liuchao173@huawei.com \
--cc=nhorman@tuxdriver.com \
--cc=peter.waskiewicz.jr@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox