On Wed, Jun 17, 2026 at 4:47 PM Breno Leitao <[email protected]> wrote: > > Hello Mateusz, > > On Wed, Jun 17, 2026 at 04:37:24PM +0200, Oleg Nesterov wrote: > > On 06/17, Mateusz Guzik wrote: > > > > > > There are trivial touch ups which can be done by adding a bunch of > > > predicts and inlining kill_fasync if someone can be bothered. > > > > I was thinking about another change, see below. It assumes that in the > > likely case another writer won't steal the pages from ->tmp_page[] > > before we take pipe->mutex. > > Do you think we could eventually eliminate the tmp_page[] array and > consolidate everything into the prealloc pages? That would unify the two > page pools currently used in the pipe write path. > > When I examined this previously, it appeared non-trivial but potentially > feasible. >
I think I commented on this in my first e-mail. In order for this to be acceptable there would have to be a way to reclaim these pages in case of memory shortage. Otherwise, say you cached 8 pages and the pipe remains unused afterwards -- all the pages are actively being wasted with no means to free them. Now that I wrote it though, I think this is very much doable. Naively you could add a list for all allocated pipes, but that's terrible from perf standpoint even if said list is distributed enough to not have contention on pipe creation/destruction in a real setting. But suppose pipes are allocated from a dedicated slab. There is presumably a way to walk all of the created pipes, regardless if they are is "allocated" or "freed", in which case such shrinker could be implemented without extra overhead for the write side. Someone familiar with slab (slub?) internals would have to chime in though.
