Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Wed, 1 Nov 2023 11:28:43 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     Jiaxun Yang <jiaxun.yang@flygoat.com>,
        Linux-Arch <linux-arch@vger.kernel.org>, 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
Message-ID: <20231101102843.GJ15024@noisy.programming.kicks-ass.net>
References: <82076999-9346-473d-8841-1480cd70b527@app.fastmail.com>
 <f548e9e7-e499-4e26-87d9-c45ce69236a1@app.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f548e9e7-e499-4e26-87d9-c45ce69236a1@app.fastmail.com>
Precedence: bulk

On Wed, Nov 01, 2023 at 10:08:42AM +0100, Arnd Bergmann wrote:
> 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.

And here I looked at iowrite8 and find it includes tracing and all
sorts, which means it is unsuitable for things like early-serial and the
shiny new atomic write functionality of said serial-8250.