From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> To: David Howells <dhowells@redhat.com> Cc: torvalds@linux-foundation.org, Rasmus Villemoes <linux@rasmusvillemoes.dk>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Peter Zijlstra <peterz@infradead.org>, nicolas.dichtel@6wind.com, raven@themaw.net, Christian Brauner <christian@brauner.io>, keyrings@vger.kernel.org, linux-usb@vger.kernel.org, linux-block@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 07/10] pipe: Conditionalise wakeup in pipe_read() [ver #2] Date: Sun, 3 Nov 2019 14:04:23 +0300 [thread overview] Message-ID: <f8810057-d92a-bcd2-c703-0a947336ce8d@yandex-team.ru> (raw) In-Reply-To: <3165.1572539884@warthog.procyon.org.uk> On 31/10/2019 19.38, David Howells wrote: > Okay, attached is a change that might give you what you want. I tried my > pipe-bench program (see cover note) with perf. The output of the program with > the patch applied was: > > - pipe 305127298 36262221772 302185181 7887690 > > The output of perf with the patch applied: > > 239,943.92 msec task-clock # 1.997 CPUs utilized > 17,728 context-switches # 73.884 M/sec > 124 cpu-migrations # 0.517 M/sec > 9,330 page-faults # 38.884 M/sec > 885,107,207,365 cycles # 3688822.793 GHz > 1,386,873,499,490 instructions # 1.57 insn per cycle > 311,037,372,339 branches # 1296296921.931 M/sec > 33,467,827 branch-misses # 0.01% of all branches > > And without: > > 239,891.87 msec task-clock # 1.997 CPUs utilized > 22,187 context-switches # 92.488 M/sec > 133 cpu-migrations # 0.554 M/sec > 9,334 page-faults # 38.909 M/sec > 884,906,976,128 cycles # 3688787.725 GHz > 1,391,986,932,265 instructions # 1.57 insn per cycle > 311,394,686,857 branches # 1298067400.849 M/sec > 30,242,823 branch-misses # 0.01% of all branches > > So it did make something like a 20% reduction in context switches. Ok. Looks promising. Depending on workload reduction might be much bigger. I suppose buffer resize (grow) makes wakeup unconditionally. Should be ok. > > David > --- > diff --git a/fs/pipe.c b/fs/pipe.c > index e3d5f7a39123..5167921edd73 100644 > --- a/fs/pipe.c > +++ b/fs/pipe.c > @@ -276,7 +276,7 @@ pipe_read(struct kiocb *iocb, struct iov_iter *to) > size_t total_len = iov_iter_count(to); > struct file *filp = iocb->ki_filp; > struct pipe_inode_info *pipe = filp->private_data; > - int do_wakeup; > + int do_wakeup, wake; > ssize_t ret; > > /* Null read succeeds. */ > @@ -329,11 +329,12 @@ pipe_read(struct kiocb *iocb, struct iov_iter *to) > tail++; > pipe->tail = tail; > do_wakeup = 1; > - if (head - (tail - 1) == pipe->max_usage) > + wake = head - (tail - 1) == pipe->max_usage / 2; > + if (wake) > wake_up_interruptible_sync_poll_locked( > &pipe->wait, EPOLLOUT | EPOLLWRNORM); > spin_unlock_irq(&pipe->wait.lock); > - if (head - (tail - 1) == pipe->max_usage) > + if (wake) > kill_fasync(&pipe->fasync_writers, SIGIO, POLL_OUT); > } > total_len -= chars; >
WARNING: multiple messages have this Message-ID (diff)
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> To: David Howells <dhowells@redhat.com> Cc: torvalds@linux-foundation.org, Rasmus Villemoes <linux@rasmusvillemoes.dk>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Peter Zijlstra <peterz@infradead.org>, nicolas.dichtel@6wind.com, raven@themaw.net, Christian Brauner <christian@brauner.io>, keyrings@vger.kernel.org, linux-usb@vger.kernel.org, linux-block@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 07/10] pipe: Conditionalise wakeup in pipe_read() [ver #2] Date: Sun, 03 Nov 2019 11:04:23 +0000 [thread overview] Message-ID: <f8810057-d92a-bcd2-c703-0a947336ce8d@yandex-team.ru> (raw) In-Reply-To: <3165.1572539884@warthog.procyon.org.uk> On 31/10/2019 19.38, David Howells wrote: > Okay, attached is a change that might give you what you want. I tried my > pipe-bench program (see cover note) with perf. The output of the program with > the patch applied was: > > - pipe 305127298 36262221772 302185181 7887690 > > The output of perf with the patch applied: > > 239,943.92 msec task-clock # 1.997 CPUs utilized > 17,728 context-switches # 73.884 M/sec > 124 cpu-migrations # 0.517 M/sec > 9,330 page-faults # 38.884 M/sec > 885,107,207,365 cycles # 3688822.793 GHz > 1,386,873,499,490 instructions # 1.57 insn per cycle > 311,037,372,339 branches # 1296296921.931 M/sec > 33,467,827 branch-misses # 0.01% of all branches > > And without: > > 239,891.87 msec task-clock # 1.997 CPUs utilized > 22,187 context-switches # 92.488 M/sec > 133 cpu-migrations # 0.554 M/sec > 9,334 page-faults # 38.909 M/sec > 884,906,976,128 cycles # 3688787.725 GHz > 1,391,986,932,265 instructions # 1.57 insn per cycle > 311,394,686,857 branches # 1298067400.849 M/sec > 30,242,823 branch-misses # 0.01% of all branches > > So it did make something like a 20% reduction in context switches. Ok. Looks promising. Depending on workload reduction might be much bigger. I suppose buffer resize (grow) makes wakeup unconditionally. Should be ok. > > David > --- > diff --git a/fs/pipe.c b/fs/pipe.c > index e3d5f7a39123..5167921edd73 100644 > --- a/fs/pipe.c > +++ b/fs/pipe.c > @@ -276,7 +276,7 @@ pipe_read(struct kiocb *iocb, struct iov_iter *to) > size_t total_len = iov_iter_count(to); > struct file *filp = iocb->ki_filp; > struct pipe_inode_info *pipe = filp->private_data; > - int do_wakeup; > + int do_wakeup, wake; > ssize_t ret; > > /* Null read succeeds. */ > @@ -329,11 +329,12 @@ pipe_read(struct kiocb *iocb, struct iov_iter *to) > tail++; > pipe->tail = tail; > do_wakeup = 1; > - if (head - (tail - 1) = pipe->max_usage) > + wake = head - (tail - 1) = pipe->max_usage / 2; > + if (wake) > wake_up_interruptible_sync_poll_locked( > &pipe->wait, EPOLLOUT | EPOLLWRNORM); > spin_unlock_irq(&pipe->wait.lock); > - if (head - (tail - 1) = pipe->max_usage) > + if (wake) > kill_fasync(&pipe->fasync_writers, SIGIO, POLL_OUT); > } > total_len -= chars; >
next prev parent reply other threads:[~2019-11-03 11:04 UTC|newest] Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-23 20:17 [RFC PATCH 00/10] pipe: Notification queue preparation [ver #2] David Howells 2019-10-23 20:17 ` David Howells 2019-10-23 20:17 ` David Howells 2019-10-23 20:17 ` [RFC PATCH 01/10] pipe: Reduce #inclusion of pipe_fs_i.h " David Howells 2019-10-23 20:17 ` David Howells 2019-10-23 20:17 ` David Howells 2019-10-23 20:17 ` [RFC PATCH 02/10] Remove the nr_exclusive argument from __wake_up_sync_key() " David Howells 2019-10-23 20:17 ` David Howells 2019-10-23 20:17 ` David Howells 2019-10-23 20:17 ` [RFC PATCH 03/10] Add wake_up_interruptible_sync_poll_locked() " David Howells 2019-10-23 20:17 ` David Howells 2019-10-23 20:17 ` David Howells 2019-10-23 20:17 ` [RFC PATCH 04/10] pipe: Use head and tail pointers for the ring, not cursor and length " David Howells 2019-10-23 20:17 ` David Howells 2019-10-23 20:17 ` David Howells 2019-10-26 0:29 ` kbuild test robot 2019-10-26 0:50 ` kbuild test robot 2019-10-26 14:58 ` [pipe] 6567a02d20: BUG:kernel_NULL_pointer_dereference,address kernel test robot 2019-10-26 14:58 ` kernel test robot 2019-10-26 14:58 ` kernel test robot 2019-10-27 14:03 ` [RFC PATCH 04/10] pipe: Use head and tail pointers for the ring, not cursor and length [ver #2] Linus Torvalds 2019-10-27 14:03 ` Linus Torvalds 2019-10-30 16:19 ` Ilya Dryomov 2019-10-30 16:19 ` Ilya Dryomov 2019-10-30 20:35 ` Rasmus Villemoes 2019-10-30 20:35 ` Rasmus Villemoes 2019-10-30 22:16 ` Ilya Dryomov 2019-10-30 22:16 ` Ilya Dryomov 2019-10-30 22:38 ` Rasmus Villemoes 2019-10-30 22:38 ` Rasmus Villemoes 2019-10-31 15:11 ` David Howells 2019-10-31 15:57 ` Ilya Dryomov 2019-10-31 15:57 ` Ilya Dryomov 2019-11-01 14:53 ` David Howells 2019-10-31 14:57 ` David Howells 2019-11-03 11:17 ` Matthew Wilcox 2019-11-03 11:17 ` Matthew Wilcox 2019-12-06 21:47 ` Johannes Hirte 2019-12-06 21:47 ` Johannes Hirte 2019-12-06 22:14 ` Linus Torvalds 2019-12-06 22:14 ` Linus Torvalds 2019-12-07 0:00 ` Johannes Hirte 2019-12-07 0:00 ` Johannes Hirte 2019-12-07 1:03 ` Linus Torvalds 2019-12-07 1:03 ` Linus Torvalds 2019-12-08 17:56 ` Johannes Hirte 2019-12-08 17:56 ` Johannes Hirte 2019-12-08 18:10 ` Linus Torvalds 2019-12-08 18:10 ` Linus Torvalds 2019-12-07 6:47 ` Linus Torvalds 2019-12-07 6:47 ` Linus Torvalds 2019-12-06 22:15 ` David Howells 2019-10-23 20:17 ` [RFC PATCH 05/10] pipe: Allow pipes to have kernel-reserved slots " David Howells 2019-10-23 20:17 ` David Howells 2019-10-23 20:17 ` David Howells 2019-10-23 20:18 ` [RFC PATCH 06/10] pipe: Advance tail pointer inside of wait spinlock in pipe_read() " David Howells 2019-10-23 20:18 ` David Howells 2019-10-23 20:18 ` David Howells 2019-10-23 20:18 ` [RFC PATCH 07/10] pipe: Conditionalise wakeup " David Howells 2019-10-23 20:18 ` David Howells 2019-10-23 20:18 ` David Howells 2019-10-27 15:57 ` Konstantin Khlebnikov 2019-10-27 15:57 ` Konstantin Khlebnikov 2019-10-31 15:21 ` David Howells 2019-10-31 16:38 ` David Howells 2019-11-03 11:04 ` Konstantin Khlebnikov [this message] 2019-11-03 11:04 ` Konstantin Khlebnikov 2019-10-23 20:18 ` [RFC PATCH 08/10] pipe: Rearrange sequence in pipe_write() to preallocate slot " David Howells 2019-10-23 20:18 ` David Howells 2019-10-23 20:18 ` David Howells 2019-10-23 20:18 ` [RFC PATCH 09/10] pipe: Remove redundant wakeup from pipe_write() " David Howells 2019-10-23 20:18 ` David Howells 2019-10-23 20:18 ` David Howells 2019-10-23 20:18 ` [RFC PATCH 10/10] pipe: Check for ring full inside of the spinlock in " David Howells 2019-10-23 20:18 ` David Howells 2019-10-23 20:18 ` David Howells 2019-10-24 10:32 ` [RFC PATCH 04/10] pipe: Use head and tail pointers for the ring, not cursor and length " David Howells 2019-10-24 10:32 ` David Howells 2019-10-24 13:14 ` [RFC PATCH 00/10] pipe: Notification queue preparation " Peter Zijlstra 2019-10-24 13:14 ` Peter Zijlstra 2019-10-24 16:57 ` [RFC PATCH 11/10] pipe: Add fsync() support " David Howells 2019-10-24 16:57 ` David Howells 2019-10-24 21:29 ` Linus Torvalds 2019-10-24 21:29 ` Linus Torvalds 2019-10-25 8:34 ` David Howells 2019-10-25 8:34 ` David Howells 2019-10-27 15:22 ` Christoph Hellwig 2019-10-27 15:22 ` Christoph Hellwig 2019-10-27 16:04 ` Konstantin Khlebnikov 2019-10-27 16:04 ` Konstantin Khlebnikov 2019-10-31 15:13 ` David Howells 2019-10-31 15:15 ` David Howells 2019-11-02 18:53 ` Linus Torvalds 2019-11-02 18:53 ` Linus Torvalds 2019-11-02 19:34 ` David Howells 2019-11-02 20:31 ` Andy Lutomirski 2019-11-02 20:31 ` Andy Lutomirski 2019-11-02 22:03 ` Linus Torvalds 2019-11-02 22:03 ` Linus Torvalds 2019-11-02 22:09 ` Linus Torvalds 2019-11-02 22:09 ` Linus Torvalds 2019-11-02 22:30 ` Andy Lutomirski 2019-11-02 22:30 ` Andy Lutomirski 2019-11-02 23:02 ` Linus Torvalds 2019-11-02 23:02 ` Linus Torvalds 2019-11-02 23:09 ` Linus Torvalds 2019-11-02 23:09 ` Linus Torvalds 2019-11-02 23:14 ` Andy Lutomirski 2019-11-02 23:14 ` Andy Lutomirski 2019-11-03 12:02 ` Konstantin Khlebnikov 2019-11-03 12:02 ` Konstantin Khlebnikov
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=f8810057-d92a-bcd2-c703-0a947336ce8d@yandex-team.ru \ --to=khlebnikov@yandex-team.ru \ --cc=christian@brauner.io \ --cc=dhowells@redhat.com \ --cc=gregkh@linuxfoundation.org \ --cc=keyrings@vger.kernel.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-block@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=linux@rasmusvillemoes.dk \ --cc=nicolas.dichtel@6wind.com \ --cc=peterz@infradead.org \ --cc=raven@themaw.net \ --cc=torvalds@linux-foundation.org \ /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: linkBe 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.