Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4784430ybl; Wed, 22 Jan 2020 04:44:19 -0800 (PST) X-Google-Smtp-Source: APXvYqweREyUdHOitpY9vfTTTSDk57RIi5PVAHpv4iqL5tUMz9U09OjaWIOi/utTJzZTmO8GXdcR X-Received: by 2002:a54:4117:: with SMTP id l23mr6302361oic.140.1579697059478; Wed, 22 Jan 2020 04:44:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579697059; cv=none; d=google.com; s=arc-20160816; b=cpYS+o/zvFvA0x/j+Yrt6r1dXzjvu9wl58C7+rFE7wEySap+n6lDN3rI9haLPMUMsQ GoorsjjHiyXGNJ2QQcVV9W3NE7vIp4/Gza8k/v3uHmDb8PLzVhXVP1wESiSOy+z0iTUt tqsSecIvGmfQCd2lL2JbqBvwQ3FailTbTZLRH0x8h0FPtYeJsrbRWUFoDXxVUwlg3dI0 8GRK12tqBiQvi9c4CU4+F6KAQbpuIndf8D/tJfWVCkVZbEY8E2GpTERIk8jLrwgrWr3F OB5CwBYGaxwVcpRwhvN3Jci0FehaJFvOq+SeXk0fwwcS8bSKpVDgKOzbV1jYQ12G3ZU/ VDDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=dZU+QLiol7Vt/roD5AkGub8upEnltvHO14BrMnYhp0w=; b=xbMhjXlqoejtKNF4zlqvjjsxBKOmVyP9/z8nnL/ZXC71MQg1dHh2uBhrSvs6bibwPv yRi/QHkvvUW1Ho8n0Xmk6NRRZvD6ujDrQhVuXQlDzyUp9hgw4mTTJkuYuGOi2Hprlqh8 HeGKrlAihavangYhDOXaD8gclyk/qyih+ZKjNRc6we0U4b1T74PCsT7TdeceLgF8zVBw BzTvfGdcyskHcnBHzkrWg/HLW5AlWW/vCkRpP1aIMJhoKmfNFAO4/cVrDoxtNnc98vnB B4v6yG33F0409zqL78a9lXiJ29vfnOsXWCyJ9qydIvain9jJzvy1iqTU7e0AuNS0VtMZ pkaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a15si23252432otq.83.2020.01.22.04.44.06; Wed, 22 Jan 2020 04:44:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729017AbgAVMnK (ORCPT + 99 others); Wed, 22 Jan 2020 07:43:10 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:37650 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726204AbgAVMnJ (ORCPT ); Wed, 22 Jan 2020 07:43:09 -0500 Received: from [5.158.153.52] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iuFLM-0003OI-VI; Wed, 22 Jan 2020 13:42:49 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 8960C101F92; Wed, 22 Jan 2020 13:42:48 +0100 (CET) From: Thomas Gleixner To: l00520965 Cc: linfeilong@huawei.com, hushiyuan@huawei.com, LiuChao , linux-kernel@vger.kernel.org, PJ Waskiewicz , Neil Horman Subject: Re: [RFC] irq: Skip printing irq when desc->action is null even if any_count is not zero In-Reply-To: <20200121130959.22589-1-liuchao173@huawei.com> References: <20200121130959.22589-1-liuchao173@huawei.com> Date: Wed, 22 Jan 2020 13:42:48 +0100 Message-ID: <87k15jek6v.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Chao, l00520965 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 > Reviewed-by: Thomas Gleixner 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