From: Breno Leitao <leitao@debian.org>
To: Mateusz Guzik <mjguzik@gmail.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Shuah Khan <shuah@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, usama.arif@linux.dev,
kernel-team@meta.com
Subject: Re: [PATCH 1/2] fs/pipe: bulk pre-allocate pages outside pipe->mutex in anon_pipe_write
Date: Fri, 22 May 2026 05:10:31 -0700 [thread overview]
Message-ID: <ahBGd-VwsZN7BGYm@gmail.com> (raw)
In-Reply-To: <CAGudoHGMVQTU-5bh5csvZDgXv_aXun5-eSSGRoONxgSZAcF6Rg@mail.gmail.com>
On Thu, May 21, 2026 at 07:26:48PM +0200, Mateusz Guzik wrote:
> On Thu, May 21, 2026 at 5:38 PM Breno Leitao <leitao@debian.org> wrote:
>
> I do suspect the best way forward in the long run is repopulate the
> tmp_page array if you have pages to do so.
Ack!
> > + struct anon_pipe_prealloc prealloc = {};
> >
>
> I forgot this bit is going to be a problem with gcc. I verified it
> emits rep stosq in place, which is going to completely unnecessarily
> slow things down especially on older uarchs. This is a known bug with
> gcc doing terrible job optimizing this.
>
> The problem will be avoided by merely initializing the count to 0.
> which looks kind of ugly if done here, but see below.
Ack, I can do it inside anon_pipe_get_page_prealloc()
static void anon_pipe_get_page_prealloc(struct anon_pipe_prealloc *prealloc,
size_t total_len)
{
prealloc->count = 0;
if (total_len <= PAGE_SIZE)
return;
...
}
> > + /*
> > + * Bulk pre-allocate pages outside pipe->mutex for writes that span more
> > + * than one full page. alloc_page() with GFP_HIGHUSER may sleep doing
> > + * reclaim and runs memcg charging, so doing it under the mutex
> > + * extends the critical section and stalls the reader. The merge path
> > + * handles sub-PAGE_SIZE writes without a fresh page; single-page and
> > + * >PIPE_PREALLOC_MAX-page writes fall back to alloc_page() under the
> > + * mutex for the remainder.
> > + */
> > + if (total_len > PAGE_SIZE)
> > + anon_pipe_get_page_prealloc(&prealloc, total_len);
> > +
>
> I don't think this comment belongs here, it should move above the
> prealloc routine.
>
> How about this: anon_pipe_get_page_prealloc gets called
> unconditionally and expects an uninitialized prealloc struct. For
> total_len > PAGE_SIZE you roll with the current code. Otherwise you
> just set ->count to 0, which prevents the ->pages array from being
> looked at. You can even pre-set to 0 on entry, just don't memset the
> entire obj.
Thanks, let me respin a v2.
--breno
next prev parent reply other threads:[~2026-05-22 12:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-15 10:28 [PATCH 0/2] fs/pipe: reduce pipe->mutex contention by bulk-allocating outside the lock Breno Leitao
2026-05-15 10:28 ` [PATCH 1/2] fs/pipe: bulk pre-allocate pages outside pipe->mutex in anon_pipe_write Breno Leitao
2026-05-15 20:18 ` Mateusz Guzik
2026-05-20 17:09 ` Breno Leitao
2026-05-21 12:58 ` Mateusz Guzik
2026-05-21 15:38 ` Breno Leitao
2026-05-21 17:26 ` Mateusz Guzik
2026-05-22 12:10 ` Breno Leitao [this message]
2026-05-15 10:28 ` [PATCH 2/2] selftests/pipe: add pipe_bench microbenchmark Breno Leitao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ahBGd-VwsZN7BGYm@gmail.com \
--to=leitao@debian.org \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=kernel-team@meta.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mjguzik@gmail.com \
--cc=shuah@kernel.org \
--cc=usama.arif@linux.dev \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.