https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-13833 Lustre <p>In upstream kernel commit <tt>v3.0-rc7-226-g0e1fdafd9398</tt>, the filesystem can implement icache/dcache shrinkers on a per-superblock basis:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>commit 0e1fdafd93980eac62e778798549ce0f6073905c Author: Dave Chinner &lt;dchinner@redhat.com&gt; AuthorDate: Fri Jul 8 14:14:44 2011 +1000 Commit: Al Viro &lt;viro@zeniv.linux.org.uk&gt; CommitDate: Wed Jul 20 20:47:41 2011 -0400 superblock: add filesystem shrinker operations Now we have a per-superblock shrinker implementation, we can add a filesystem specific callout to it to allow filesystem internal caches to be shrunk by the superblock shrinker. Rather than perpetuate the multipurpose shrinker callback API (i.e. nr_to_scan == 0 meaning "tell me how many objects freeable in the cache), two operations will be added. The first will return the number of objects that are freeable, the second is the actual shrinker call. Signed-off-by: Dave Chinner &lt;dchinner@redhat.com&gt; Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt; </pre> </div></div> <p>It would be useful to hook the client dcache/icache/LDLM cache into these shrinker callbacks so that it can more effectively manage cache sizes on clients. </p> LU-13833

hook llite to inode cache shrinker

Bug Major Open Unresolved WC Triage Andreas Dilger upstream Thu, 30 Jul 2020 09:24:40 +0000 Wed, 10 Nov 2021 00:58:54 +0000 Upstream 0 9 <p>To fix this problem properly, it may be enough to check here if there is any DLM lock on the inode, and drop the inode if not?</p> <p>Something like the following in <tt>ll_drop_inode()</tt>:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-keyword">if</span> (!md_lock_match(ll_i2mdexp(inode), ..., ll_i2fid(inode), ...)) <span class="code-keyword">return</span> 1; </pre> </div></div> <p>The main question is which lock mode/bits/flags to be used for the matched? The inode/layout lock should not be dropped if it is being used for IO or has dirty data (that is already impossible in an active syscall, but maybe between syscalls), but should be dropped when there are no more DLM locks (MDC or OSC) using the inode, since any future access will need an MDS RPC to revalidate anyway.</p> <p>A possibly more efficient option would be to add a refcount to ll_inode_info with the number of DLM locks attached to it, so that it can be checked more efficiently instead of a lock match. The refcount could be added to the inode after lli_inode_magic, since there is a 4-byte hole.</p> <p>The DLM locks shouldn't (I think?) __iget() the VFS inode <b>itself</b> for each lock to avoid a circular dependency where inodes cannot be dropped from cache when they have any DLM locks, since that may pin a lot of inodes. The counter argument would that the DLM locks would eventually be dropped from cache themselves (LRU, slab shrinker), so the inode refcount would be finite, but adds some interdependency.</p> Related LU-12511 LU-14408 LU-13983 LU-13970 Development Rank 1|i016iv: Rank (Obsolete) 9223372036854775807 Severity