From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Andreas Gruenbacher <agruenba@redhat.com>,
Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
"Darrick J. Wong" <djwong@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Dave Chinner <david@fromorbit.com>,
Brian Foster <bfoster@redhat.com>,
Ojaswin Mujoo <ojaswin@linux.ibm.com>,
Disha Goel <disgoel@linux.ibm.com>
Subject: Re: [PATCHv9 3/6] iomap: Add some uptodate state handling helpers for ifs state bitmap
Date: Mon, 12 Jun 2023 20:48:16 +0530 [thread overview]
Message-ID: <87o7lkhfpj.fsf@doe.com> (raw)
In-Reply-To: <CAHc6FU5xMQfGPuTBDChS=w2+t4KAbu9po7yE+7qGaLTzV-+AFw@mail.gmail.com>
Andreas Gruenbacher <agruenba@redhat.com> writes:
> On Mon, Jun 12, 2023 at 8:25 AM Christoph Hellwig <hch@infradead.org> wrote:
>> On Sat, Jun 10, 2023 at 05:09:04PM +0530, Ritesh Harjani (IBM) wrote:
>> > This patch adds two of the helper routines iomap_ifs_is_fully_uptodate()
>> > and iomap_ifs_is_block_uptodate() for managing uptodate state of
>> > ifs state bitmap.
>> >
>> > In later patches ifs state bitmap array will also handle dirty state of all
>> > blocks of a folio. Hence this patch adds some helper routines for handling
>> > uptodate state of the ifs state bitmap.
>> >
>> > Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>> > ---
>> > fs/iomap/buffered-io.c | 28 ++++++++++++++++++++--------
>> > 1 file changed, 20 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
>> > index e237f2b786bc..206808f6e818 100644
>> > --- a/fs/iomap/buffered-io.c
>> > +++ b/fs/iomap/buffered-io.c
>> > @@ -43,6 +43,20 @@ static inline struct iomap_folio_state *iomap_get_ifs(struct folio *folio)
>> >
>> > static struct bio_set iomap_ioend_bioset;
>> >
>> > +static inline bool iomap_ifs_is_fully_uptodate(struct folio *folio,
>> > + struct iomap_folio_state *ifs)
>> > +{
>> > + struct inode *inode = folio->mapping->host;
>> > +
>> > + return bitmap_full(ifs->state, i_blocks_per_folio(inode, folio));
>> > +}
>> > +
>> > +static inline bool iomap_ifs_is_block_uptodate(struct iomap_folio_state *ifs,
>> > + unsigned int block)
>> > +{
>> > + return test_bit(block, ifs->state);
>
> "block_is_uptodate" instead of "is_block_uptodate" here as well, please.
>
> Also see by previous mail about iomap_ifs_is_block_uptodate().
>
"is_block_uptodate" is what we decided in our previous discussion here [1]
[1]: https://lore.kernel.org/linux-xfs/20230605225434.GF1325469@frogsfrogsfrogs/
Unless any strong objections, for now I will keep Maintainer's suggested name
;) and wait for his feedback on this.
>> > +}
>>
>> A little nitpicky, but do the _ifs_ name compenents here really add
>> value?
>
> Since we're at the nitpicking, I don't find those names very useful,
> either. How about the following instead?
>
> iomap_ifs_alloc -> iomap_folio_state_alloc
> iomap_ifs_free -> iomap_folio_state_free
> iomap_ifs_calc_range -> iomap_folio_state_calc_range
First of all I think we need to get used to the name "ifs" like how we
were using "iop" earlier. ifs == iomap_folio_state...
>
> iomap_ifs_is_fully_uptodate -> iomap_folio_is_fully_uptodate
> iomap_ifs_is_block_uptodate -> iomap_block_is_uptodate
> iomap_ifs_is_block_dirty -> iomap_block_is_dirty
>
...if you then look above functions with _ifs_ == _iomap_folio_state_
naming. It will make more sense.
> iomap_ifs_set_range_uptodate -> __iomap_set_range_uptodate
> iomap_ifs_clear_range_dirty -> __iomap_clear_range_dirty
> iomap_ifs_set_range_dirty -> __iomap_set_range_dirty
Same as above.
>
> Thanks,
> Andreas
Thanks for the review!
I am not saying I am not open to changing the name. But AFAIR, Darrick
and Matthew were ok with "ifs" naming. In fact they first suggested it
as well. So if others also dislike "ifs" naming, then we could consider
other options.
-ritesh
next prev parent reply other threads:[~2023-06-12 15:18 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-10 11:39 [PATCHv9 0/6] iomap: Add support for per-block dirty state to improve write performance Ritesh Harjani (IBM)
2023-06-10 11:39 ` [PATCHv9 1/6] iomap: Rename iomap_page to iomap_folio_state and others Ritesh Harjani (IBM)
2023-06-12 6:21 ` Christoph Hellwig
2023-06-12 6:23 ` Christoph Hellwig
2023-06-12 9:19 ` Ritesh Harjani
2023-06-12 15:05 ` Darrick J. Wong
2023-06-12 15:08 ` Matthew Wilcox
2023-06-12 15:59 ` Darrick J. Wong
2023-06-12 17:43 ` Ritesh Harjani
2023-06-12 17:54 ` Matthew Wilcox
2023-06-13 5:05 ` Christoph Hellwig
2023-06-10 11:39 ` [PATCHv9 2/6] iomap: Drop ifs argument from iomap_set_range_uptodate() Ritesh Harjani (IBM)
2023-06-12 6:24 ` Christoph Hellwig
2023-06-10 11:39 ` [PATCHv9 3/6] iomap: Add some uptodate state handling helpers for ifs state bitmap Ritesh Harjani (IBM)
2023-06-12 6:25 ` Christoph Hellwig
2023-06-12 9:14 ` Ritesh Harjani
2023-06-12 12:54 ` Andreas Gruenbacher
2023-06-12 15:18 ` Ritesh Harjani [this message]
2023-06-12 15:24 ` Matthew Wilcox
2023-06-12 15:33 ` Ritesh Harjani
2023-06-12 15:57 ` Andreas Gruenbacher
2023-06-12 16:10 ` Darrick J. Wong
2023-06-12 17:54 ` Ritesh Harjani
2023-06-12 12:40 ` Andreas Gruenbacher
2023-06-12 15:30 ` Ritesh Harjani
2023-06-12 16:14 ` Andreas Grünbacher
2023-06-12 16:16 ` Darrick J. Wong
2023-06-12 16:19 ` Andreas Gruenbacher
2023-06-12 17:57 ` Ritesh Harjani
2023-06-10 11:39 ` [PATCHv9 4/6] iomap: Refactor iomap_write_delalloc_punch() function out Ritesh Harjani (IBM)
2023-06-12 6:25 ` Christoph Hellwig
2023-06-12 9:01 ` Ritesh Harjani
2023-06-12 13:22 ` Matthew Wilcox
2023-06-12 14:03 ` Ritesh Harjani
2023-06-12 14:19 ` Matthew Wilcox
2023-06-12 13:56 ` Pankaj Raghav
2023-06-12 14:55 ` Ritesh Harjani
2023-06-10 11:39 ` [PATCHv9 5/6] iomap: Allocate ifs in ->write_begin() early Ritesh Harjani (IBM)
2023-06-10 11:39 ` [PATCHv9 6/6] iomap: Add per-block dirty state tracking to improve performance Ritesh Harjani (IBM)
2023-06-12 6:30 ` Christoph Hellwig
2023-06-12 9:00 ` Ritesh Harjani
2023-06-12 16:27 ` Matthew Wilcox
2023-06-15 15:03 ` [PATCHv9 0/6] iomap: Add support for per-block dirty state to improve write performance Ritesh Harjani
2023-06-15 16:12 ` Ritesh Harjani
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=87o7lkhfpj.fsf@doe.com \
--to=ritesh.list@gmail.com \
--cc=agruenba@redhat.com \
--cc=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=disgoel@linux.ibm.com \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox