All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darrick J. Wong <djwong@kernel.org>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH v5 7/9] iomap/xfs: Eliminate the iomap_valid handler
Date: Tue, 10 Jan 2023 13:56:44 -0800	[thread overview]
Message-ID: <Y73fHN4aDfbo6e1z@magnolia> (raw)
In-Reply-To: <CAHc6FU40OYCpRjnitmKn6s9LOZCy4O=4XobHdcUeFc=k=x5cGg@mail.gmail.com>

On Sun, Jan 08, 2023 at 07:50:01PM +0100, Andreas Gruenbacher wrote:
> On Sun, Jan 8, 2023 at 6:32 PM Christoph Hellwig <hch@infradead.org> wrote:
> > On Wed, Jan 04, 2023 at 07:08:17PM +0000, Matthew Wilcox wrote:
> > > On Wed, Jan 04, 2023 at 09:53:17AM -0800, Darrick J. Wong wrote:
> > > > I wonder if this should be reworked a bit to reduce indenting:
> > > >
> > > >     if (PTR_ERR(folio) == -ESTALE) {
> > >
> > > FYI this is a bad habit to be in.  The compiler can optimise
> > >
> > >       if (folio == ERR_PTR(-ESTALE))
> > >
> > > better than it can optimise the other way around.
> >
> > Yes.  I think doing the recording that Darrick suggested combined
> > with this style would be best:
> >
> >         if (folio == ERR_PTR(-ESTALE)) {
> >                 iter->iomap.flags |= IOMAP_F_STALE;
> >                 return 0;
> >         }
> >         if (IS_ERR(folio))
> >                 return PTR_ERR(folio);
> 
> Again, I've implemented this as a nested if because the -ESTALE case
> should be pretty rare, and if we unnest, we end up with an additional
> check on the main code path. To be specific, the "before" code here on
> my current system is this:
> 
> ------------------------------------
>         if (IS_ERR(folio)) {
>     22ad:       48 81 fd 00 f0 ff ff    cmp    $0xfffffffffffff000,%rbp
>     22b4:       0f 87 bf 03 00 00       ja     2679 <iomap_write_begin+0x499>
>                         return 0;
>                 }
>                 return PTR_ERR(folio);
>         }
> [...]
>     2679:       89 e8                   mov    %ebp,%eax
>                 if (folio == ERR_PTR(-ESTALE)) {
>     267b:       48 83 fd 8c             cmp    $0xffffffffffffff8c,%rbp
>     267f:       0f 85 b7 fc ff ff       jne    233c <iomap_write_begin+0x15c>
>                         iter->iomap.flags |= IOMAP_F_STALE;
>     2685:       66 81 4b 42 00 02       orw    $0x200,0x42(%rbx)
>                         return 0;
>     268b:       e9 aa fc ff ff          jmp    233a <iomap_write_begin+0x15a>
> ------------------------------------
> 
> While the "after" code is this:
> 
> ------------------------------------
>         if (folio == ERR_PTR(-ESTALE)) {
>     22ad:       48 83 fd 8c             cmp    $0xffffffffffffff8c,%rbp
>     22b1:       0f 84 bc 00 00 00       je     2373 <iomap_write_begin+0x193>
>                 iter->iomap.flags |= IOMAP_F_STALE;
>                 return 0;
>         }
>         if (IS_ERR(folio))
>                 return PTR_ERR(folio);
>     22b7:       89 e8                   mov    %ebp,%eax
>         if (IS_ERR(folio))
>     22b9:       48 81 fd 00 f0 ff ff    cmp    $0xfffffffffffff000,%rbp
>     22c0:       0f 87 82 00 00 00       ja     2348 <iomap_write_begin+0x168>
> ------------------------------------
> 
> The compiler isn't smart enough to re-nest the ifs by recognizing that
> folio == ERR_PTR(-ESTALE) is a subset of IS_ERR(folio).
> 
> So do you still insist on that un-nesting even though it produces worse code?

Me?  Not anymore. :)

--D

> Thanks,
> Andreas
> 


WARNING: multiple messages have this Message-ID (diff)
From: "Darrick J. Wong" <djwong@kernel.org>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Matthew Wilcox <willy@infradead.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-ext4@vger.kernel.org, cluster-devel@redhat.com
Subject: Re: [PATCH v5 7/9] iomap/xfs: Eliminate the iomap_valid handler
Date: Tue, 10 Jan 2023 13:56:44 -0800	[thread overview]
Message-ID: <Y73fHN4aDfbo6e1z@magnolia> (raw)
In-Reply-To: <CAHc6FU40OYCpRjnitmKn6s9LOZCy4O=4XobHdcUeFc=k=x5cGg@mail.gmail.com>

On Sun, Jan 08, 2023 at 07:50:01PM +0100, Andreas Gruenbacher wrote:
> On Sun, Jan 8, 2023 at 6:32 PM Christoph Hellwig <hch@infradead.org> wrote:
> > On Wed, Jan 04, 2023 at 07:08:17PM +0000, Matthew Wilcox wrote:
> > > On Wed, Jan 04, 2023 at 09:53:17AM -0800, Darrick J. Wong wrote:
> > > > I wonder if this should be reworked a bit to reduce indenting:
> > > >
> > > >     if (PTR_ERR(folio) == -ESTALE) {
> > >
> > > FYI this is a bad habit to be in.  The compiler can optimise
> > >
> > >       if (folio == ERR_PTR(-ESTALE))
> > >
> > > better than it can optimise the other way around.
> >
> > Yes.  I think doing the recording that Darrick suggested combined
> > with this style would be best:
> >
> >         if (folio == ERR_PTR(-ESTALE)) {
> >                 iter->iomap.flags |= IOMAP_F_STALE;
> >                 return 0;
> >         }
> >         if (IS_ERR(folio))
> >                 return PTR_ERR(folio);
> 
> Again, I've implemented this as a nested if because the -ESTALE case
> should be pretty rare, and if we unnest, we end up with an additional
> check on the main code path. To be specific, the "before" code here on
> my current system is this:
> 
> ------------------------------------
>         if (IS_ERR(folio)) {
>     22ad:       48 81 fd 00 f0 ff ff    cmp    $0xfffffffffffff000,%rbp
>     22b4:       0f 87 bf 03 00 00       ja     2679 <iomap_write_begin+0x499>
>                         return 0;
>                 }
>                 return PTR_ERR(folio);
>         }
> [...]
>     2679:       89 e8                   mov    %ebp,%eax
>                 if (folio == ERR_PTR(-ESTALE)) {
>     267b:       48 83 fd 8c             cmp    $0xffffffffffffff8c,%rbp
>     267f:       0f 85 b7 fc ff ff       jne    233c <iomap_write_begin+0x15c>
>                         iter->iomap.flags |= IOMAP_F_STALE;
>     2685:       66 81 4b 42 00 02       orw    $0x200,0x42(%rbx)
>                         return 0;
>     268b:       e9 aa fc ff ff          jmp    233a <iomap_write_begin+0x15a>
> ------------------------------------
> 
> While the "after" code is this:
> 
> ------------------------------------
>         if (folio == ERR_PTR(-ESTALE)) {
>     22ad:       48 83 fd 8c             cmp    $0xffffffffffffff8c,%rbp
>     22b1:       0f 84 bc 00 00 00       je     2373 <iomap_write_begin+0x193>
>                 iter->iomap.flags |= IOMAP_F_STALE;
>                 return 0;
>         }
>         if (IS_ERR(folio))
>                 return PTR_ERR(folio);
>     22b7:       89 e8                   mov    %ebp,%eax
>         if (IS_ERR(folio))
>     22b9:       48 81 fd 00 f0 ff ff    cmp    $0xfffffffffffff000,%rbp
>     22c0:       0f 87 82 00 00 00       ja     2348 <iomap_write_begin+0x168>
> ------------------------------------
> 
> The compiler isn't smart enough to re-nest the ifs by recognizing that
> folio == ERR_PTR(-ESTALE) is a subset of IS_ERR(folio).
> 
> So do you still insist on that un-nesting even though it produces worse code?

Me?  Not anymore. :)

--D

> Thanks,
> Andreas
> 

  reply	other threads:[~2023-01-10 21:56 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-31 15:09 [Cluster-devel] [PATCH v5 0/9] Turn iomap_page_ops into iomap_folio_ops Andreas Gruenbacher
2022-12-31 15:09 ` Andreas Gruenbacher
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 1/9] iomap: Add iomap_put_folio helper Andreas Gruenbacher
2022-12-31 15:09   ` Andreas Gruenbacher
2023-01-04 17:39   ` [Cluster-devel] " Darrick J. Wong
2023-01-04 17:39     ` Darrick J. Wong
2023-01-08 17:25   ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:25     ` Christoph Hellwig
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 2/9] iomap/gfs2: Unlock and put folio in page_done handler Andreas Gruenbacher
2022-12-31 15:09   ` Andreas Gruenbacher
2023-01-04 17:40   ` [Cluster-devel] " Darrick J. Wong
2023-01-04 17:40     ` Darrick J. Wong
2023-01-08 17:26   ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:26     ` Christoph Hellwig
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 3/9] iomap: Rename page_done handler to put_folio Andreas Gruenbacher
2022-12-31 15:09   ` Andreas Gruenbacher
2023-01-04 17:37   ` [Cluster-devel] " Darrick J. Wong
2023-01-04 17:37     ` Darrick J. Wong
2023-01-04 18:51     ` [Cluster-devel] " Andreas Grünbacher
2023-01-04 18:51       ` Andreas Grünbacher
2023-01-08 17:26   ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:26     ` Christoph Hellwig
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 4/9] iomap: Add iomap_get_folio helper Andreas Gruenbacher
2022-12-31 15:09   ` Andreas Gruenbacher
2023-01-04 17:38   ` [Cluster-devel] " Darrick J. Wong
2023-01-04 17:38     ` Darrick J. Wong
2023-01-08 17:26   ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:26     ` Christoph Hellwig
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 5/9] iomap/gfs2: Get page in page_prepare handler Andreas Gruenbacher
2022-12-31 15:09   ` Andreas Gruenbacher
2023-01-04 17:45   ` [Cluster-devel] " Darrick J. Wong
2023-01-04 17:45     ` Darrick J. Wong
2023-01-08 17:29   ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:29     ` Christoph Hellwig
2023-01-08 19:40     ` [Cluster-devel] " Andreas Gruenbacher
2023-01-08 19:40       ` Andreas Gruenbacher
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 6/9] iomap: Rename page_prepare handler to get_folio Andreas Gruenbacher
2022-12-31 15:09   ` Andreas Gruenbacher
2023-01-04 17:46   ` [Cluster-devel] " Darrick J. Wong
2023-01-04 17:46     ` Darrick J. Wong
2023-01-08 17:31   ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:31     ` Christoph Hellwig
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 7/9] iomap/xfs: Eliminate the iomap_valid handler Andreas Gruenbacher
2022-12-31 15:09   ` Andreas Gruenbacher
2023-01-04 17:53   ` [Cluster-devel] " Darrick J. Wong
2023-01-04 17:53     ` Darrick J. Wong
2023-01-04 19:02     ` [Cluster-devel] " Andreas Grünbacher
2023-01-04 19:02       ` Andreas Grünbacher
2023-01-04 19:08     ` [Cluster-devel] " Matthew Wilcox
2023-01-04 19:08       ` Matthew Wilcox
2023-01-08 17:32       ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:32         ` Christoph Hellwig
2023-01-08 18:50         ` [Cluster-devel] " Andreas Gruenbacher
2023-01-08 18:50           ` Andreas Gruenbacher
2023-01-10 21:56           ` Darrick J. Wong [this message]
2023-01-10 21:56             ` Darrick J. Wong
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 8/9] iomap: Rename page_ops to folio_ops Andreas Gruenbacher
2022-12-31 15:09   ` Andreas Gruenbacher
2023-01-04 17:53   ` [Cluster-devel] " Darrick J. Wong
2023-01-04 17:53     ` Darrick J. Wong
2023-01-08 17:33   ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:33     ` Christoph Hellwig
2022-12-31 15:09 ` [Cluster-devel] [PATCH v5 9/9] xfs: Make xfs_iomap_folio_ops static Andreas Gruenbacher
2022-12-31 15:09   ` Andreas Gruenbacher
2023-01-08 17:33   ` [Cluster-devel] " Christoph Hellwig
2023-01-08 17:33     ` 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=Y73fHN4aDfbo6e1z@magnolia \
    --to=djwong@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.