> -----Original Message----- > From: Waiman Long [mailto:longman@xxxxxxxxxx] > Sent: Friday, August 18, 2017 10:10 PM > To: Wangkai (Kevin,C); Alexander Viro; Jonathan Corbet > Cc: linux-kernel@xxxxxxxxxxxxxxx; linux-doc@xxxxxxxxxxxxxxx; > linux-fsdevel@xxxxxxxxxxxxxxx; Paul E. McKenney; Andrew Morton; Ingo Molnar; > Miklos Szeredi; Matthew Wilcox; Larry Woodman; James Bottomley > Subject: Re: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries > > On 08/18/2017 05:59 AM, Wangkai (Kevin,C) wrote: > > > >>> In my patch the DCACHE_FILE_REMOVED flag was to distinguish the > >>> removed file and The closed file, I found there was no difference of > >>> a dentry between the removed file and the closed File, they all on the lru > list. > >> There is a difference between removed file and closed file. The type > >> field of d_flags will be empty for a removed file which indicate a negative > dentry. > >> Anything else is a positive dentry. Look at the inline function > >> d_is_negative() [d_is_miss()] and you will see how it is done. > > After the file was removed, the dentry flag was not MISS, the flag was: > > DCACHE_REFERENCED | DCACHE_RCUACCESS | DCACHE_LRU_LIST | > > DCACHE_REGULAR_TYPE So, the dentry never be freed, until the kernel > reclaim the slab memory. > > The dentry_unlink_inode() function will clear DCACHE_REGULAR_TYPE. > Yes, I have add some trace info for the dentry state changed, with dentry flag and reference count: File create: [ 42.636675] dentry [xxxx_1234] 0xffff880230be8180 flag 0x0 ref 1 ev dentry alloc File close: [ 42.637421] dentry [xxxx_1234] 0xffff880230be8180 flag 0x4800c0 ref 0 ev dput called Unlink lookup: [ 244.658086] dentry [xxxx_1234] 0xffff880230be8180 flag 0x4800c0 ref 1 ev d_lookup Unlink d_delete: [ 244.658254] dentry [xxxx_1234] 0xffff880230be8180 flag 0x800c0 ref 1 ev d_lockref ref 1 Unlink dput: [ 244.658438] dentry [xxxx_1234] 0xffff880230be8180 flag 0x800c0 ref 0 ev dput called The end, dentry's flag stay at 0x800c0, but this dentry was not freed, keeped by the dcache as unused, After tens of thousands of the dentries slow down the dentry lookup performance, kernel memory usage Keep high. Regards, Kevin ��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
