All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Hongbo Li <lihongbo22@huawei.com>
Cc: kent.overstreet@linux.dev, linux-bcachefs@vger.kernel.org
Subject: Re: [PATCH RFC 1/2] bcachefs: use btree_path_state to represent btree_path status
Date: Wed, 20 Mar 2024 13:39:49 -0400	[thread overview]
Message-ID: <ZfsfZby1X6XAbhql@bfoster> (raw)
In-Reply-To: <20240320062923.305431-2-lihongbo22@huawei.com>

On Wed, Mar 20, 2024 at 02:29:22PM +0800, Hongbo Li wrote:
> First, the old structure cannot clearly represent the state changes
> of btree_path (such as BTREE_ITER_xxx). Secondly, the member (
> btree_path->uptodate) cannot express its purpose intuitively. It's
> essentially a state value if I understand correctly. Using this way
> can makes the representation of member variables more reasonable.
> 
> Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
> ---
>  fs/bcachefs/btree_iter.c         | 22 +++++++++++-----------
>  fs/bcachefs/btree_iter.h         |  6 +++---
>  fs/bcachefs/btree_key_cache.c    | 12 ++++++------
>  fs/bcachefs/btree_locking.c      | 14 +++++++-------
>  fs/bcachefs/btree_locking.h      |  8 ++++----
>  fs/bcachefs/btree_trans_commit.c |  2 +-
>  fs/bcachefs/btree_types.h        | 10 +++++-----
>  7 files changed, 37 insertions(+), 37 deletions(-)
> 
...
> diff --git a/fs/bcachefs/btree_types.h b/fs/bcachefs/btree_types.h
> index 9404d96c38f3..7146d6cf9fba 100644
> --- a/fs/bcachefs/btree_types.h
> +++ b/fs/bcachefs/btree_types.h
> @@ -218,10 +218,10 @@ static const __maybe_unused u16 BTREE_ITER_CACHED_NOFILL	= 1 << 13;
>  static const __maybe_unused u16 BTREE_ITER_KEY_CACHE_FILL	= 1 << 14;
>  #define __BTREE_ITER_FLAGS_END					       15
>  
> -enum btree_path_uptodate {
> -	BTREE_ITER_UPTODATE		= 0,
> -	BTREE_ITER_NEED_RELOCK		= 1,
> -	BTREE_ITER_NEED_TRAVERSE	= 2,
> +enum btree_path_state {
> +        UPTODATE		= 0,
> +        NEED_RELOCK		= 1,
> +        NEED_TRAVERSE		= 2
>  };
>  
>  #if defined(CONFIG_BCACHEFS_LOCK_TIME_STATS) || defined(CONFIG_BCACHEFS_DEBUG)
> @@ -241,7 +241,7 @@ struct btree_path {
>  	enum btree_id		btree_id:5;
>  	bool			cached:1;
>  	bool			preserve:1;
> -	enum btree_path_uptodate uptodate:2;
> +	enum btree_path_state   status:2;

Personally I don't mind the field rename, but the loss of any prefix on
the flags urks me a bit. Any reason not to use something like
BTREE_PATH_UPTODATE..?

It also would be nice to be consistent between the field and enum names.
Perhaps rename the field to 'state' if it's of type btree_path_state?

Finally, if we are going to tweak this, it seems like a nice opportunity
to add a comment above btree_path_state to (briefly) explain what each
state means and perhaps how they relate.

Just my .02 of course. ;)

Brian

>  	/*
>  	 * When true, failing to relock this path will cause the transaction to
>  	 * restart:
> -- 
> 2.34.1
> 


  reply	other threads:[~2024-03-20 17:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-20  6:29 [PATCH RFC 0/2] bcachefs: refactoring of btree_path status Hongbo Li
2024-03-20  6:29 ` [PATCH RFC 1/2] bcachefs: use btree_path_state to represent " Hongbo Li
2024-03-20 17:39   ` Brian Foster [this message]
2024-03-20 19:57     ` Kent Overstreet
2024-03-20 20:10   ` Kent Overstreet
2024-03-20  6:29 ` [PATCH RFC 2/2] bcachefs: optimize btree_path status representation Hongbo Li
2024-03-20 17:41   ` Brian Foster
2024-03-20 20:50     ` Kent Overstreet
2024-03-21  1:53     ` Hongbo Li
2024-03-20 20:06   ` Kent Overstreet
2024-03-21  1:44     ` Hongbo Li
2024-03-20 19:43 ` [PATCH RFC 0/2] bcachefs: refactoring of btree_path status Kent Overstreet
2024-03-20 19:55   ` Kent Overstreet
2024-03-21  2:00     ` Hongbo Li

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=ZfsfZby1X6XAbhql@bfoster \
    --to=bfoster@redhat.com \
    --cc=kent.overstreet@linux.dev \
    --cc=lihongbo22@huawei.com \
    --cc=linux-bcachefs@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.