Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1048-g9229b632c5-fm-20231019.001-g9229b632
MIME-Version: 1.0
Message-Id: <f548e9e7-e499-4e26-87d9-c45ce69236a1@app.fastmail.com>
In-Reply-To: <82076999-9346-473d-8841-1480cd70b527@app.fastmail.com>
References: <82076999-9346-473d-8841-1480cd70b527@app.fastmail.com>
Date:   Wed, 01 Nov 2023 10:08:42 +0100
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Jiaxun Yang" <jiaxun.yang@flygoat.com>,
        Linux-Arch <linux-arch@vger.kernel.org>
Cc:     x86@kernel.org, linux-kernel@vger.kernel.org,
        "Baoquan He" <bhe@redhat.com>
Subject: Re: Overhead of io{read,write}{8,16,32,64} on x86
Content-Type: text/plain
Precedence: bulk

On Tue, Oct 31, 2023, at 22:41, Jiaxun Yang wrote:
> Hi all,
>
> I'm trying to improve Kernel's support of devices that have ioports
> mapped into MMIO, that involves converting existing driver which is
> using {in,out}{l,w,b} to use io{read,write}{8,16,32,64}, so they can
> benefit from ioport_map and pci_iomap.
>
> However, the problem is io{read,write}{8,16,32,64} will incur penalty
> on x86 by introducing extra function calls (they are not inlined) and
> having extra condition judgment on MMIO vs PIO.
>
> x86 folks, do you think this kind of overhead is acceptable? I do think
> most of PCI/ISA drivers will need to be converted.
>
> linux-arch folks, do you think it will be better if we introduce a
> variant of io{read,write}{8,16,32,64} that direct to PIO on x86 but
> remains the same functionality on other architectures?

I think in general there is not much of a problem here since
the inb()/outb() operations themselves are extremely slow already,
in particular the outb() writes are non-posted unlike writeb().

My feeling is that converting to ioread/iowrite is generally a win
for any driver that already needs to support both cases (e.g.
serial-8250) since this can unify the two code paths.

However, for drivers that only support inb()/outb() today, I don't
see a real benefit in converting them from the traditional methods.

Another question is whether we actually want to keep the ISA-only
drivers around. Usually once you look closely, any particular
ISA driver tends to be entirely unused already and can be removed,
aside from a few known devices that are either soldered-down on
motherboards or that have an LPC variant using the same ISA driver.

     Arnd