All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Pavel Begunkov <asml.silence@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iov_iter: optimise iter type checking
Date: Sat, 9 Jan 2021 17:03:59 +0000	[thread overview]
Message-ID: <20210109170359.GT3579531@ZenIV.linux.org.uk> (raw)
In-Reply-To: <54cd4d1b-d7ec-a74c-8be0-e48780609d56@gmail.com>

On Sat, Jan 09, 2021 at 04:09:08PM +0000, Pavel Begunkov wrote:
> On 06/12/2020 16:01, Pavel Begunkov wrote:
> > On 21/11/2020 14:37, Pavel Begunkov wrote:
> >> The problem here is that iov_iter_is_*() helpers check types for
> >> equality, but all iterate_* helpers do bitwise ands. This confuses
> >> compilers, so even if some cases were handled separately with
> >> iov_iter_is_*(), corresponding ifs in iterate*() right after are not
> >> eliminated.
> >>
> >> E.g. iov_iter_npages() first handles discards, but iterate_all_kinds()
> >> still checks for discard iter type and generates unreachable code down
> >> the line.
> > 
> > Ping. This one should be pretty simple
> 
> Ping please. Any doubts about this patch?

Sorry, had been buried in other crap.  I'm really not fond of the
bitmap use; if anything, I would rather turn iterate_and_advance() et.al.
into switches...

How about moving the READ/WRITE part into MSB?  Checking is just as fast
(if not faster - check for sign vs. checking bit 0).  And turn the
types into straight (dense) enum.

Almost all iov_iter_rw() callers have the form (iov_iter_rw(iter) == READ) or
(iov_iter_rw(iter) == WRITE).  Out of 50-odd callers there are 5 nominal
exceptions:
fs/cifs/smbdirect.c:1936:                        iov_iter_rw(&msg->msg_iter));
fs/exfat/inode.c:442:   int rw = iov_iter_rw(iter);
fs/f2fs/data.c:3639:    int rw = iov_iter_rw(iter);
fs/f2fs/f2fs.h:4082:    int rw = iov_iter_rw(iter);
fs/f2fs/f2fs.h:4092:    int rw = iov_iter_rw(iter);

The first one is debugging printk
        if (iov_iter_rw(&msg->msg_iter) == WRITE) {
                /* It's a bug in upper layer to get there */
                cifs_dbg(VFS, "Invalid msg iter dir %u\n",
                         iov_iter_rw(&msg->msg_iter));
                rc = -EINVAL;
                goto out;
        }
and if you look at the condition, the quality of message is
underwhelming - "Data source msg iter passed by caller" would
be more informative.

Other 4...  exfat one is
        if (rw == WRITE) {
...
	}
...
        if (ret < 0 && (rw & WRITE))
                exfat_write_failed(mapping, size);
IOW, doing
	bool is_write = iov_iter_rw(iter) == WRITE;
would be cleaner.  f2fs.h ones are
	int rw = iov_iter_rw(iter);
	....
	if (.... && rw == WRITE ...
so they are of the same sort (assuming we want that local
variable in the first place).

f2fs/data.c is the least trivial - it includes things like
                if (!down_read_trylock(&fi->i_gc_rwsem[rw])) {
and considering the amount of other stuff done there,
I would suggest something like
	int rw = is_data_source(iter) ? WRITE : READ;

I'll dig myself from under ->d_revalidate() code review, look
through the iov_iter-related series and post review, hopefully
by tonight.

  reply	other threads:[~2021-01-09 17:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-21 14:37 [PATCH] iov_iter: optimise iter type checking Pavel Begunkov
2020-12-06 16:01 ` Pavel Begunkov
2021-01-09 16:09   ` Pavel Begunkov
2021-01-09 17:03     ` Al Viro [this message]
2021-01-09 21:19       ` Pavel Begunkov
2021-01-09 21:49       ` David Laight
2021-01-09 22:11         ` Pavel Begunkov
2021-01-11  9:35           ` David Laight
2021-01-12 16:04             ` Pavel Begunkov
2021-01-16  5:18           ` Al Viro
2021-01-17 12:12             ` David Laight
2021-01-27 15:48             ` Pavel Begunkov
2021-01-27 16:28               ` David Laight
2021-01-27 18:30                 ` Al Viro
2021-01-27 18:31               ` Al Viro
2021-01-28 11:39                 ` Pavel Begunkov

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=20210109170359.GT3579531@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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.