fs/dcache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
dentry_cmp() has predicts inside, but they were not enough to convince
the compiler.
As for difference in asm, some of the code is reshuffled and there is
one less unconditional jump to get there.
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
---
i know it's late, but given the non-semantic-modifying nature of the
change, i think it can still make it for 6.19
fs/dcache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index 23d1752c29e6..bc84f89156fa 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -2346,7 +2346,7 @@ struct dentry *__d_lookup_rcu(const struct dentry *parent,
continue;
if (dentry->d_name.hash_len != hashlen)
continue;
- if (dentry_cmp(dentry, str, hashlen_len(hashlen)) != 0)
+ if (unlikely(dentry_cmp(dentry, str, hashlen_len(hashlen)) != 0))
continue;
*seqp = seq;
return dentry;
--
2.34.1
On Thu 27-11-25 13:24:12, Mateusz Guzik wrote: > dentry_cmp() has predicts inside, but they were not enough to convince > the compiler. > > As for difference in asm, some of the code is reshuffled and there is > one less unconditional jump to get there. > > Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> I've checked and on my laptop the dentry hash table has ~2 million entries. This means we'll be getting hash collisions within a directory for directories on the order of thousands entries. And until we get to hundreds of thousands of entries in a directory, the collisions of entries will be still rare. So I guess that's rare enough. Feel free to add: Reviewed-by: Jan Kara <jack@suse.cz> Honza > --- > > i know it's late, but given the non-semantic-modifying nature of the > change, i think it can still make it for 6.19 > > fs/dcache.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/dcache.c b/fs/dcache.c > index 23d1752c29e6..bc84f89156fa 100644 > --- a/fs/dcache.c > +++ b/fs/dcache.c > @@ -2346,7 +2346,7 @@ struct dentry *__d_lookup_rcu(const struct dentry *parent, > continue; > if (dentry->d_name.hash_len != hashlen) > continue; > - if (dentry_cmp(dentry, str, hashlen_len(hashlen)) != 0) > + if (unlikely(dentry_cmp(dentry, str, hashlen_len(hashlen)) != 0)) > continue; > *seqp = seq; > return dentry; > -- > 2.34.1 > -- Jan Kara <jack@suse.com> SUSE Labs, CR
On Thu, Nov 27, 2025 at 2:52 PM Jan Kara <jack@suse.cz> wrote: > > On Thu 27-11-25 13:24:12, Mateusz Guzik wrote: > > dentry_cmp() has predicts inside, but they were not enough to convince > > the compiler. > > > > As for difference in asm, some of the code is reshuffled and there is > > one less unconditional jump to get there. > > > > Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> > > I've checked and on my laptop the dentry hash table has ~2 million entries. > This means we'll be getting hash collisions within a directory for > directories on the order of thousands entries. And until we get to hundreds > of thousands of entries in a directory, the collisions of entries will be > still rare. So I guess that's rare enough. Feel free to add: > collisions with the same parent are a given, but with the same length on top should be rare > Reviewed-by: Jan Kara <jack@suse.cz> thanks, but see v2 :) https://lore.kernel.org/linux-fsdevel/20251127131526.4137768-1-mjguzik@gmail.com/T/#u > > Honza > > > --- > > > > i know it's late, but given the non-semantic-modifying nature of the > > change, i think it can still make it for 6.19 > > > > fs/dcache.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/fs/dcache.c b/fs/dcache.c > > index 23d1752c29e6..bc84f89156fa 100644 > > --- a/fs/dcache.c > > +++ b/fs/dcache.c > > @@ -2346,7 +2346,7 @@ struct dentry *__d_lookup_rcu(const struct dentry *parent, > > continue; > > if (dentry->d_name.hash_len != hashlen) > > continue; > > - if (dentry_cmp(dentry, str, hashlen_len(hashlen)) != 0) > > + if (unlikely(dentry_cmp(dentry, str, hashlen_len(hashlen)) != 0)) > > continue; > > *seqp = seq; > > return dentry; > > -- > > 2.34.1 > > > -- > Jan Kara <jack@suse.com> > SUSE Labs, CR
© 2016 - 2025 Red Hat, Inc.