In the fast path, the value of "p" in __rht_ptr() should be valid.
Therefore, wrap it with a "likely". The performance increasing is tiny,
but it's still worth to do it.

Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
---
 include/linux/rhashtable.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
index e740157f3cd7..a8e38a74acf5 100644
--- a/include/linux/rhashtable.h
+++ b/include/linux/rhashtable.h
@@ -358,9 +358,10 @@ static inline void rht_unlock(struct bucket_table *tbl,
 static inline struct rhash_head *__rht_ptr(
 	struct rhash_lock_head *p, struct rhash_lock_head __rcu *const *bkt)
 {
+	unsigned long p_val = (unsigned long)p & ~BIT(0);
+
 	return (struct rhash_head *)
-		((unsigned long)p & ~BIT(0) ?:
-		 (unsigned long)RHT_NULLS_MARKER(bkt));
+		(likely(p_val) ? p_val : (unsigned long)RHT_NULLS_MARKER(bkt));
 }
 
 /*
-- 
2.51.0

Menglong Dong <menglong8.dong@gmail.com> wrote:
> In the fast path, the value of "p" in __rht_ptr() should be valid.
> Therefore, wrap it with a "likely". The performance increasing is tiny,
> but it's still worth to do it.
> 
> Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
> ---
> include/linux/rhashtable.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)

It's not obvious that rht_ptr would be non-NULL.  It depends on the
work load.  For example, if you're doing a lookup where most keys
are non-existent then it would most likely be NULL.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

On Tue, Sep 23, 2025 at 2:36 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> Menglong Dong <menglong8.dong@gmail.com> wrote:
> > In the fast path, the value of "p" in __rht_ptr() should be valid.
> > Therefore, wrap it with a "likely". The performance increasing is tiny,
> > but it's still worth to do it.
> >
> > Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
> > ---
> > include/linux/rhashtable.h | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
>
> It's not obvious that rht_ptr would be non-NULL.  It depends on the
> work load.  For example, if you're doing a lookup where most keys
> are non-existent then it would most likely be NULL.

Yeah, I see. In my case, the usage of the rhashtable will be:
add -> lookup, and rht_ptr is alway non-NULL. You are right,
it can be NULL in other situations, and it's not a good idea to
use likely() here ;)

Thanks!
Menglong Dong

>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt