Re: [PATCH 3/3] dcache: account external names as indirectly reclaimable memory

[Roman Gushchin <guro@fb.com>]

On Mon, Mar 12, 2018 at 09:17:42PM +0000, Al Viro wrote:
> On Mon, Mar 05, 2018 at 01:37:43PM +0000, Roman Gushchin wrote:
> > diff --git a/fs/dcache.c b/fs/dcache.c
> > index 5c7df1df81ff..a0312d73f575 100644
> > --- a/fs/dcache.c
> > +++ b/fs/dcache.c
> > @@ -273,8 +273,16 @@ static void __d_free(struct rcu_head *head)
> >  static void __d_free_external(struct rcu_head *head)
> >  {
> >  	struct dentry *dentry = container_of(head, struct dentry, d_u.d_rcu);
> > -	kfree(external_name(dentry));
> > -	kmem_cache_free(dentry_cache, dentry); 
> > +	struct external_name *name = external_name(dentry);
> > +	unsigned long bytes;
> > +
> > +	bytes = dentry->d_name.len + offsetof(struct external_name, name[1]);
> > +	mod_node_page_state(page_pgdat(virt_to_page(name)),
> > +			    NR_INDIRECTLY_RECLAIMABLE_BYTES,
> > +			    -kmalloc_size(kmalloc_index(bytes)));
> > +
> > +	kfree(name);
> > +	kmem_cache_free(dentry_cache, dentry);
> >  }
> 
> That can't be right - external names can be freed in release_dentry_name_snapshot()
> and copy_name() as well.  When do you want kfree_rcu() paths accounted for, BTW?
> At the point where we are freeing them, or where we are scheduling their freeing?

Ah, I see...

I think, it's better to account them when we're actually freeing,
otherwise we will have strange path:
(indirectly) reclaimable -> unreclaimable -> free

Do you agree?

Although it shouldn't be that important in practice.

Thank you!

--