Re: SLUB defrag pull request?

[Christoph Lameter]

Miklos Szeredi wrote:

>> There is another call to invalidate_mapping_pages() in prune_icache (that is
>> where this code originates). No i_mutex and i_alloc. Only iprune_mutex held
>> and that seems to be for the protection of the list. So just checking
>> inode->i_count would do the trick?
> 
> Yes, that's what I was saying.

Ok. Thats easy to do.

> 
>>> The big issue is dealing with umount.  You could do something like
>>> grab_super() on sb before getting a ref on the inode/dentry.  But I'm
>>> not sure this is a good idea.  There must be a simpler way to achieve
>>> this..
>> Taking a lock on vfsmount_lock? But that would make dentry reclaim a pain.
> 
> No, I mean simpler than having to do this two stage stuff.

How could it be simpler? First you need to establish a secure reference to the
object so that it cannot vanish from under us. Then all the references can be
checked and possibly removed. If we do not need a secure reference then the
get_dentries() etc method can be NULL.

>> We are only interested in the reclaim a dentry if its currently unused. If so
>> then why does unmount matter? Both unmount and reclaim will attempt to remove
>> the dentry.
>>
>> Have a look at get_dentries(). It takes the dcache_lock and checks the dentry
>> state. Either the entry is ignored or dget_locked() removes it from the lru.
>> If its off the LRU then it can no longer be reclaimed by umount.
> 
> How is that better?  You will still get busy inodes on umount.

Those inodes are going to be freed by the reclaim code. Why would they be busy
(unless the case below occurs of course).

> And anyway the dentry could be put back onto the LRU by somebody else
> between get_dentries() and kick_dentries().  So I don't even see how
> taking the dentry off the LRU helps _anything_.

get_dentries() gets a reference. dput will not put the dentry back onto the LRU.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/