From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Christian Brauner <brauner@kernel.org>,
Jeff Layton <jlayton@kernel.org>,
David Howells <dhowells@redhat.com>,
"Gautham R. Shenoy" <gautham.shenoy@amd.com>,
Mateusz Guzik <mjguzik@gmail.com>,
Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>,
Oliver Sang <oliver.sang@intel.com>,
"Swapnil Sapkal" <swapnil.sapkal@amd.com>,
WangYuli <wangyuli@uniontech.com>,
<linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: [PATCH 1/2] pipe: change pipe_write() to never add a zero-sized buffer
Date: Tue, 11 Feb 2025 09:29:02 +0530 [thread overview]
Message-ID: <fff8727a-29d7-45fe-a997-d9bd55e07f52@amd.com> (raw)
In-Reply-To: <20250210172200.GA16955@redhat.com>
Hello Oleg,
On 2/10/2025 10:52 PM, Oleg Nesterov wrote:
> Hi Prateek,
>
> On 02/10, K Prateek Nayak wrote:
>>
>> 1-groups 1.00 [ -0.00]( 7.19) 0.95 [ 4.90](12.39)
>> 2-groups 1.00 [ -0.00]( 3.54) 1.02 [ -1.92]( 6.55)
>> 4-groups 1.00 [ -0.00]( 2.78) 1.01 [ -0.85]( 2.18)
>> 8-groups 1.00 [ -0.00]( 1.04) 0.99 [ 0.63]( 0.77)
>> 16-groups 1.00 [ -0.00]( 1.02) 1.00 [ -0.26]( 0.98)
>>
>> I don't see any regression / improvements from a performance standpoint
>
> Yes, this patch shouldn't make any difference performance-wise, at least
> in this case. Although I was thinking the same thing when I sent "pipe_read:
> don't wake up the writer if the pipe is still full" ;)
>
>> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
>
> Thanks! Please see v2, I've included you tag.
Thank you. I can confirm it is same as the variant I tested.
>
> Any chance you can also test the patch below?
>
> To me it looks like a cleanup which makes the "merge small writes" logic
> more understandable. And note that "page-align the rest of the writes"
> doesn't work anyway if "total_len & (PAGE_SIZE-1)" can't fit in the last
> buffer.
>
> However, in this particular case with DATASIZE=100 this patch can increase
> the number of copy_page_from_iter()'s in pipe_write(). And with this change
> receiver() can certainly get the short reads, so this can increase the
> number of sys_read() calls.
>
> So I am just curious if this change can cause any noticeable regression on
> your machine.
For the sake of science:
==================================================================
Test : sched-messaging
Units : Normalized time in seconds
Interpretation: Lower is better
Statistic : AMean
==================================================================
Case: baseline[pct imp](CV) merge_writes[pct imp](CV)
1-groups 1.00 [ -0.00](12.39) 1.08 [ -7.62](11.73)
2-groups 1.00 [ -0.00]( 6.55) 0.97 [ 2.52]( 3.01)
4-groups 1.00 [ -0.00]( 2.18) 1.00 [ 0.42]( 1.97)
8-groups 1.00 [ -0.00]( 0.77) 1.03 [ -3.35]( 5.07)
16-groups 1.00 [ -0.00]( 0.98) 1.01 [ -1.37]( 2.20)
I see some improvements up until 4 groups (160 tasks) but beyond that it
goes into a slight regression territory but the variance is large to
draw any conclusions.
Science experiment concluded.
>
> Thank you!
>
> Oleg.
>
> --- a/fs/pipe.c
> +++ b/fs/pipe.c
> @@ -459,16 +459,16 @@ anon_pipe_write(struct kiocb *iocb, struct iov_iter *from)
> was_empty = pipe_empty(head, pipe->tail);
> chars = total_len & (PAGE_SIZE-1);
> if (chars && !was_empty) {
> - unsigned int mask = pipe->ring_size - 1;
> - struct pipe_buffer *buf = &pipe->bufs[(head - 1) & mask];
> + struct pipe_buffer *buf = pipe_buf(pipe, head - 1);
> int offset = buf->offset + buf->len;
> + int avail = PAGE_SIZE - offset;
>
> - if ((buf->flags & PIPE_BUF_FLAG_CAN_MERGE) &&
> - offset + chars <= PAGE_SIZE) {
> + if (avail && (buf->flags & PIPE_BUF_FLAG_CAN_MERGE)) {
> ret = pipe_buf_confirm(pipe, buf);
> if (ret)
> goto out;
>
> + chars = min_t(ssize_t, chars, avail);
> ret = copy_page_from_iter(buf->page, offset, chars, from);
> if (unlikely(ret < chars)) {
> ret = -EFAULT;
>
--
Thanks and Regards,
Prateek
next prev parent reply other threads:[~2025-02-11 3:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-09 15:07 [PATCH 0/2] pipe: change pipe_write() to never add a zero-sized buffer Oleg Nesterov
2025-02-09 15:07 ` [PATCH 1/2] " Oleg Nesterov
2025-02-09 17:26 ` Linus Torvalds
2025-02-09 18:02 ` Oleg Nesterov
2025-02-09 18:17 ` Linus Torvalds
2025-02-09 18:44 ` Oleg Nesterov
2025-02-09 18:52 ` Linus Torvalds
2025-02-09 19:15 ` Oleg Nesterov
2025-02-09 23:39 ` K Prateek Nayak
2025-02-10 17:22 ` Oleg Nesterov
2025-02-10 17:37 ` Linus Torvalds
2025-02-10 18:36 ` Oleg Nesterov
2025-02-11 3:59 ` K Prateek Nayak [this message]
2025-02-09 15:08 ` [PATCH 2/2] splice: add some pipe_buf_assert_len() checks Oleg Nesterov
2025-02-10 11:40 ` [PATCH v2 1/1] pipe: change pipe_write() to never add a zero-sized buffer Oleg Nesterov
2025-02-10 12:52 ` [PATCH 0/2] " Christian Brauner
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=fff8727a-29d7-45fe-a997-d9bd55e07f52@amd.com \
--to=kprateek.nayak@amd.com \
--cc=Neeraj.Upadhyay@amd.com \
--cc=brauner@kernel.org \
--cc=dhowells@redhat.com \
--cc=gautham.shenoy@amd.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjguzik@gmail.com \
--cc=oleg@redhat.com \
--cc=oliver.sang@intel.com \
--cc=swapnil.sapkal@amd.com \
--cc=torvalds@linux-foundation.org \
--cc=wangyuli@uniontech.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox