From: Al Viro <viro@ZenIV.linux.org.uk>
To: lkp@lists.01.org
Subject: Re: [lkp-robot] [fs] 3deb642f0d: will-it-scale.per_process_ops -8.8% regression
Date: Fri, 22 Jun 2018 12:01:17 +0100 [thread overview]
Message-ID: <20180622110117.GU30522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20180622100014.GA12425@lst.de>
[-- Attachment #1: Type: text/plain, Size: 2521 bytes --]
On Fri, Jun 22, 2018 at 12:00:14PM +0200, Christoph Hellwig wrote:
> And a version with select() also covered:
For fuck sake, if you want vfs_poll() inlined, *make* *it* *inlined*.
Is there any reason for not doing that other than EXPORT_SYMBOL_GPL
fetish? Because if there isn't, I would like to draw your attention
to the fact that _this_ pwecious inchewlekshul pwopewty can be trivially
open-coded by out-of-tree shite even if it happens to be non-GPL one.
> mask = vfs_poll(f.file, wait);
> + if (f.file->f_op->poll) {
... not to mention that here you forgot to remove the call itself while
expanding it.
Said that, you are not attacking the worst part of it - it's a static
branch, not the considerably more costly indirect ones. Remember when
I asked you about the price of those? Method calls are costly.
Another problem with with ->get_poll_head() calling conventions is
that originally you wanted to return ERR_PTR(-mask) as a way to report
not needing to call ->poll_mask(); that got shot down since quite
a few of those don't fit into 12 bits that ERR_PTR() gives us.
IIRC, the real reason for non-constant ->get_poll_head() was the sockets,
with
static struct wait_queue_head *sock_get_poll_head(struct file *file,
__poll_t events)
{
struct socket *sock = file->private_data;
if (!sock->ops->poll_mask)
return NULL;
sock_poll_busy_loop(sock, events);
return sk_sleep(sock->sk);
}
The first part isn't a problem (it is constant). The second is
static inline void sock_poll_busy_loop(struct socket *sock, __poll_t events)
{
if (sk_can_busy_loop(sock->sk) &&
events && (events & POLL_BUSY_LOOP)) {
/* once, only if requested by syscall */
sk_busy_loop(sock->sk, 1);
}
}
and the third -
static inline wait_queue_head_t *sk_sleep(struct sock *sk)
{
BUILD_BUG_ON(offsetof(struct socket_wq, wait) != 0);
return &rcu_dereference_raw(sk->sk_wq)->wait;
}
Now, ->sk_wq is modified only in sock_init_data() and sock_graft();
the latter, IIRC, is ->accept() helper. Do we ever call either of
those on a sock of already opened file? IOW, is there any real
reason for socket ->get_poll_head() not to be constant, other
than wanting to keep POLL_BUSY_LOOP handling out of ->poll_mask()?
I agree that POLL_BUSY_LOOP is ugly as hell, but you *still* have
sock_poll_mask() not free from it...
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Christoph Hellwig <hch@lst.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
kernel test robot <xiaolong.ye@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
LKP <lkp@01.org>
Subject: Re: [lkp-robot] [fs] 3deb642f0d: will-it-scale.per_process_ops -8.8% regression
Date: Fri, 22 Jun 2018 12:01:17 +0100 [thread overview]
Message-ID: <20180622110117.GU30522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20180622100014.GA12425@lst.de>
On Fri, Jun 22, 2018 at 12:00:14PM +0200, Christoph Hellwig wrote:
> And a version with select() also covered:
For fuck sake, if you want vfs_poll() inlined, *make* *it* *inlined*.
Is there any reason for not doing that other than EXPORT_SYMBOL_GPL
fetish? Because if there isn't, I would like to draw your attention
to the fact that _this_ pwecious inchewlekshul pwopewty can be trivially
open-coded by out-of-tree shite even if it happens to be non-GPL one.
> mask = vfs_poll(f.file, wait);
> + if (f.file->f_op->poll) {
... not to mention that here you forgot to remove the call itself while
expanding it.
Said that, you are not attacking the worst part of it - it's a static
branch, not the considerably more costly indirect ones. Remember when
I asked you about the price of those? Method calls are costly.
Another problem with with ->get_poll_head() calling conventions is
that originally you wanted to return ERR_PTR(-mask) as a way to report
not needing to call ->poll_mask(); that got shot down since quite
a few of those don't fit into 12 bits that ERR_PTR() gives us.
IIRC, the real reason for non-constant ->get_poll_head() was the sockets,
with
static struct wait_queue_head *sock_get_poll_head(struct file *file,
__poll_t events)
{
struct socket *sock = file->private_data;
if (!sock->ops->poll_mask)
return NULL;
sock_poll_busy_loop(sock, events);
return sk_sleep(sock->sk);
}
The first part isn't a problem (it is constant). The second is
static inline void sock_poll_busy_loop(struct socket *sock, __poll_t events)
{
if (sk_can_busy_loop(sock->sk) &&
events && (events & POLL_BUSY_LOOP)) {
/* once, only if requested by syscall */
sk_busy_loop(sock->sk, 1);
}
}
and the third -
static inline wait_queue_head_t *sk_sleep(struct sock *sk)
{
BUILD_BUG_ON(offsetof(struct socket_wq, wait) != 0);
return &rcu_dereference_raw(sk->sk_wq)->wait;
}
Now, ->sk_wq is modified only in sock_init_data() and sock_graft();
the latter, IIRC, is ->accept() helper. Do we ever call either of
those on a sock of already opened file? IOW, is there any real
reason for socket ->get_poll_head() not to be constant, other
than wanting to keep POLL_BUSY_LOOP handling out of ->poll_mask()?
I agree that POLL_BUSY_LOOP is ugly as hell, but you *still* have
sock_poll_mask() not free from it...
next prev parent reply other threads:[~2018-06-22 11:01 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-22 8:27 [lkp-robot] [fs] 3deb642f0d: will-it-scale.per_process_ops -8.8% regression kernel test robot
2018-06-22 8:27 ` kernel test robot
2018-06-22 9:25 ` Linus Torvalds
2018-06-22 9:25 ` Linus Torvalds
2018-06-22 9:56 ` Christoph Hellwig
2018-06-22 9:56 ` Christoph Hellwig
2018-06-22 10:00 ` Christoph Hellwig
2018-06-22 10:00 ` Christoph Hellwig
2018-06-22 11:01 ` Al Viro [this message]
2018-06-22 11:01 ` Al Viro
2018-06-22 11:53 ` Christoph Hellwig
2018-06-22 11:53 ` Christoph Hellwig
2018-06-22 11:56 ` Al Viro
2018-06-22 11:56 ` Al Viro
2018-06-22 12:07 ` Christoph Hellwig
2018-06-22 12:07 ` Christoph Hellwig
2018-06-22 12:17 ` Al Viro
2018-06-22 12:17 ` Al Viro
2018-06-22 12:33 ` Christoph Hellwig
2018-06-22 12:33 ` Christoph Hellwig
2018-06-22 12:29 ` Al Viro
2018-06-22 12:29 ` Al Viro
2018-06-22 19:06 ` Sean Paul
2018-06-22 19:06 ` Sean Paul
2018-06-22 10:02 ` Linus Torvalds
2018-06-22 10:02 ` Linus Torvalds
2018-06-22 10:05 ` Linus Torvalds
2018-06-22 10:05 ` Linus Torvalds
2018-06-22 15:02 ` Christoph Hellwig
2018-06-22 15:02 ` Christoph Hellwig
2018-06-22 15:14 ` Al Viro
2018-06-22 15:14 ` Al Viro
2018-06-22 15:28 ` Christoph Hellwig
2018-06-22 15:28 ` Christoph Hellwig
2018-06-22 16:18 ` Christoph Hellwig
2018-06-22 16:18 ` Christoph Hellwig
2018-06-22 20:02 ` Al Viro
2018-06-22 20:02 ` Al Viro
2018-06-23 7:15 ` Christoph Hellwig
2018-06-23 7:15 ` Christoph Hellwig
2018-06-26 6:03 ` Ye Xiaolong
2018-06-26 6:03 ` Ye Xiaolong
2018-06-27 7:07 ` Christoph Hellwig
2018-06-27 7:07 ` Christoph Hellwig
2018-06-28 0:38 ` Ye Xiaolong
2018-06-28 0:38 ` Ye Xiaolong
2018-06-28 13:38 ` Christoph Hellwig
2018-06-28 13:38 ` Christoph Hellwig
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=20180622110117.GU30522@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=lkp@lists.01.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: 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.