On Wed, Jun 17, 2026 at 04:57:16PM +0200, Mateusz Guzik wrote:
> 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.
Hmm, I understand scenario doesn't apply to the patch that got accepted.
The series doesn't grow the cache: tmp_page[] is still the existing 2-entry
array
anon_pipe_refill_tmp_pages() only fills empty tmp_page[] slots; every
other prealloc page is put_page()'d before the write() returns.
So an idle pipe holds at most 2 cached pages — the same cap mainline
already maintains via anon_pipe_put_page() on the release side, freed in
free_pipe_info().
/* Runs after mutex_unlock() to keep put_page() out of the critical
section. */
static void anon_pipe_free_pages(struct anon_pipe_prealloc *prealloc)
{
while (prealloc->count) {
prealloc->count--;
put_page(prealloc->pages[prealloc->count]);
}
}
Net new unreclaimable footprint from this series is zero.
