All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: l00520965 <liuchao173@huawei.com>,
	linfeilong@huawei.com, hushiyuan@huawei.com,
	linux-kernel@vger.kernel.org,
	PJ Waskiewicz <peter.waskiewicz.jr@intel.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 14:28:56 -0500	[thread overview]
Message-ID: <20200122192856.GA2852@localhost.localdomain> (raw)
In-Reply-To: <87k15jek6v.fsf@nanos.tec.linutronix.de>

On Wed, Jan 22, 2020 at 01:42:48PM +0100, Thomas Gleixner wrote:
> 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.
> 
Actually, irqbalance ignores the trailing irq name (or it should at
least), so you should be able to drop that portion of /proc/irqbalance,
though I cant speak for any other users of it.

> > 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
> 

  reply	other threads:[~2020-01-22 19:29 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
2020-01-22 19:28   ` Neil Horman [this message]
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=20200122192856.GA2852@localhost.localdomain \
    --to=nhorman@tuxdriver.com \
    --cc=hushiyuan@huawei.com \
    --cc=linfeilong@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liuchao173@huawei.com \
    --cc=peter.waskiewicz.jr@intel.com \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.