From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5B84C433DF for ; Sat, 27 Jun 2020 11:45:21 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 95BC521548 for ; Sat, 27 Jun 2020 11:45:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ucljcG8V"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="vysnINip" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 95BC521548 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=9gXXcuzs8sNG0tMDWE5kYvR61T1xx3HH5ltwfQ2Q5eE=; b=ucljcG8VBrkEbnI16w3AsFVgh yxTCd0K8d117pUW5n8Tv41ey0Y4lfpeu5I2vVzuruvDpi9J+gl/LlYaOvglv/no21fsRrniLg8j8Y mo8CIxaDmOx6DymsrEdr65CTokwS8uObUlZxDSiC2E8r8vtZ9Z03Dn6DfPF7eQ6zhm6sds4O2Ya/f 91ai3PF1mvssPWS+kOVJscARZ9T0PcMxPuItnh4tnw2Xa+/XREMy5UyfcNvi5g3ScirJRZemohga9 KXXUuSyacTpQRenwh4QkKDw9YigNJ87NJ0BtNlFhXqpYHI01eZStIS06qaVWFipmazGdUGjSLapLE PWRHpdZGw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jp9EY-0007CS-W4; Sat, 27 Jun 2020 11:42:59 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jp9EW-0007C8-Ba for linux-arm-kernel@lists.infradead.org; Sat, 27 Jun 2020 11:42:57 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 57132206A5; Sat, 27 Jun 2020 11:42:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593258174; bh=NDQ6t05q8f7nl0Bzz32uZnBANZo6lngfWP8/zQceV9A=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=vysnINipcubstwiF79XMuiPsDJpIJhFXj3Dd6E9Rpbt0liu0a/RWvw0vESdl3R1KY e2DI3uBy0F8BsNB/gEV3TXlBclyJZvIppVmTBbSzSz121VZP4OShYNiMyK8TVzCyn2 vViLNkHkNsE8DkhdvFIkP8j5+eavxcSX4o1x9Neg= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jp9ES-006sH2-Qh; Sat, 27 Jun 2020 12:42:52 +0100 MIME-Version: 1.0 Date: Sat, 27 Jun 2020 12:42:52 +0100 From: Marc Zyngier To: Valentin Schneider Subject: Re: [PATCH v2 15/17] arm64: Remove custom IRQ stat accounting In-Reply-To: References: <20200624195811.435857-1-maz@kernel.org> <20200624195811.435857-16-maz@kernel.org> User-Agent: Roundcube Webmail/1.4.5 Message-ID: <2f41d622f1f9e41026e93c2dc18aa65b@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: valentin.schneider@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, catalin.marinas@arm.com, linux@arm.linux.org.uk, tglx@linutronix.de, jason@lakedaemon.net, sumit.garg@linaro.org, f.fainelli@gmail.com, gregory.clement@bootlin.com, andrew@lunn.ch, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sumit Garg , Florian Fainelli , Russell King , Jason Cooper , kernel-team@android.com, Andrew Lunn , Catalin Marinas , Gregory Clement , linux-kernel@vger.kernel.org, Thomas Gleixner , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-06-27 00:15, Valentin Schneider wrote: > On 26/06/20 12:58, Marc Zyngier wrote: >> On 2020-06-25 19:26, Valentin Schneider wrote: >>> On 24/06/20 20:58, Marc Zyngier wrote: >>>> @@ -801,26 +802,15 @@ void show_ipi_list(struct seq_file *p, int >>>> prec) >>>> unsigned int cpu, i; >>>> >>>> for (i = 0; i < NR_IPI; i++) { >>>> + unsigned int irq = irq_desc_get_irq(ipi_desc[i]); >>>> seq_printf(p, "%*s%u:%s", prec - 1, "IPI", i, >>>> prec >= 4 ? " " : ""); >>>> for_each_online_cpu(cpu) >>>> - seq_printf(p, "%10u ", >>>> - __get_irq_stat(cpu, ipi_irqs[i])); >>>> + seq_printf(p, "%10u ", kstat_irqs_cpu(irq, cpu)); >>>> seq_printf(p, " %s\n", ipi_types[i]); >>> >>> How attached are we to that custom IPI printout? AIUI we *could* give >>> them >>> a "prettier" name in request_percpu_irq() and let the standard procfs >>> printout take the wheel. >> >> I wish. Unfortunately, /proc/interrupts is likely to be considered >> ABI, >> and I'm really worried to change this (see what happened last time we >> tried to update /proc/cpuinfo to be less braindead...). >> > > Hmph, it's borderline here I think: we're not introducing a new field > or > format in the file, so any tool that can parse /proc/interrupts can > parse > the IPIs if they are formatted like the other "regular" interrupts. But > then said tool could die in flames when not seeing the special IPI > fields > because sturdiness is overrated :( Which is exactly what I'm worried about. People do stupid things, and stupidity becomes ABI. I hate luserspace. M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel