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=-9.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 A0B77C433ED for ; Tue, 6 Apr 2021 12:14:57 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 3B49D613BD for ; Tue, 6 Apr 2021 12:14:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3B49D613BD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4FF60b6XdFz3cFV for ; Tue, 6 Apr 2021 22:14:55 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=maz@kernel.org; receiver=) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4FF5yN5mY8z3c0x for ; Tue, 6 Apr 2021 22:13:00 +1000 (AEST) 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 0BC03613C2; Tue, 6 Apr 2021 12:12:58 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lTkZk-005qpW-3r; Tue, 06 Apr 2021 13:12:56 +0100 Date: Tue, 06 Apr 2021 13:12:55 +0100 Message-ID: <87lf9vpq60.wl-maz@kernel.org> From: Marc Zyngier To: Christophe Leroy Subject: Re: [PATCH 1/9] irqdomain: Reimplement irq_linear_revmap() with irq_find_mapping() In-Reply-To: <15be426f-4429-ebeb-1b4a-8342bce391e5@csgroup.eu> References: <20210406093557.1073423-1-maz@kernel.org> <20210406093557.1073423-2-maz@kernel.org> <15be426f-4429-ebeb-1b4a-8342bce391e5@csgroup.eu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: christophe.leroy@csgroup.eu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, tsbogend@alpha.franken.de, ysato@users.sourceforge.jp, haojian.zhuang@gmail.com, dalias@libc.org, tglx@linutronix.de, robert.jarzmik@free.fr, daniel@zonque.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thomas Bogendoerfer , Yoshinori Sato , linux-sh@vger.kernel.org, Robert Jarzmik , linux-kernel@vger.kernel.org, Haojian Zhuang , linux-mips@vger.kernel.org, Rich Felker , Daniel Mack , Thomas Gleixner , linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Christophe, On Tue, 06 Apr 2021 12:21:33 +0100, Christophe Leroy wrote: >=20 >=20 >=20 > Le 06/04/2021 =C3=A0 11:35, Marc Zyngier a =C3=A9crit=C2=A0: > > irq_linear_revmap() is supposed to be a fast path for domain > > lookups, but it only exposes low-level details of the irqdomain > > implementation, details which are better kept private. >=20 > Can you elaborate with more details ? Things like directly picking into the revmap are positively awful, and doesn't work if the domain has been constructed using the radix tree. Which on its own is totally broken, because things like irq_domain_create_hierarchy() will pick an implementation or the other. >=20 > >=20 > > The *overhead* between the two is only a function call and > > a couple of tests, so it is likely that noone can show any > > meaningful difference compared to the cost of taking an > > interrupt. >=20 > Do you have any measurement ? I did measure things on arm64, and couldn't come up with any difference other than noise. > Can you make the "likely" a certitude ? Of course not. You can always come up with an artificial CPU implementation that has a very small exception entry overhead, and a ridiculously slow memory subsystem. Do I care about these? No. If you can come up with realistic platforms that show a regression with this patch, I'm all ears. >=20 > >=20 > > Reimplement irq_linear_revmap() with irq_find_mapping() > > in order to preserve source code compatibility, and > > rename the internal field for a measure. >=20 > This is in complete contradiction with commit https://github.com/torvalds= /linux/commit/d3dcb436 >=20 > At that time, irq_linear_revmap() was less complex than what > irq_find_mapping() is today, and nevertheless it was considered worth > restoring in as a fast path. What has changed since then ? Over 8 years? Plenty. The use of irqdomains has been generalised, we have domain hierarchies, and if anything, this commit introduces the buggy behaviour I was mentioning above. I also don't see any mention of actual performance in that commit. And if we're worried about a fast path, being able to directly cache the irq_data in the revmap, hence skipping the irq_desc lookup that inevitable follows, is a much more interesting prospect than the "get useless data quick" that irq_linear_revmap() implements. This latter optimisation is what I am after. > Can you also explain the reason for the renaming of "linear_revmap" > into "revmap" ? What is that "measure" ? To catch the potential direct use of the reverse map field. Thanks, M. --=20 Without deviation from the norm, progress is not possible.