Re: [linus:master] [fs/pipe] f7f4665dc5: lmbench3.PIPE.bandwidth.MB/sec 18.5% regression

[Breno Leitao <leitao@debian.org>]

On Tue, Nov 10, 2026 at 03:44:36PM +0100, Mateusz Guzik wrote:
> On Tue, Nov 10, 2026 at 1:46 PM Breno Leitao <leitao@debian.org> wrote:
> >
> > On Fri, Nov 06, 2026 at 02:44:54PM +0100, Mateusz Guzik wrote:
> > > > 6) Any other idea?
> > >
> > > The SMAP stuff is the primary problem right now. To reiterate: every
> > > single buffer read/write takes a SMAP trip, which is very expensive
> > > even on modern uarchs. Refactoring this into i/o under one SMAP round
> > > would provide a visible speed up. It also happens to not pose a
> > > tradeoff in terms of memory usage and would be my first avenue of
> > > attack if I was working on this.
> > >
> > > All that said, one reader vs one writer scenario definitely makes
> > > sense to optimize.
> >
> > I've spent some tokens on it, and it seems to give ~5% improvement on
> > the pipe bench. Is this what you had in mind (in a single patch format)?
> >
> 
> The resulting behavior matches.
> 
> A clean implementation escapes me and that's part of a reason I did
> not do the work myself.
> 
> The proposed patch is on the uglier side, but AFAICS that was never a
> blocker in Linux.

Agree, the implementation is not beatiful. Another approach is to open
code and have a single function to do the whole copying, and simplify it
a bit, but, that makes the code even harder to digest.

Let me try to come up with something a bit more digestible and see where
I will end up.

thanks,
--breno