Message ID | 1558685161-860-1-git-send-email-stummala@codeaurora.org (mailing list archive) |
---|---|
State | Rejected |
Headers | show |
Series | mm/vmscan.c: drop all inode/dentry cache from LRU | expand |
On Fri, May 24, 2019 at 4:06 PM Sahitya Tummala <stummala@codeaurora.org> wrote: > > This is important for the scenario where FBE (file based encryption) > is enabled. With FBE, the encryption context needed to en/decrypt a file > will be stored in inode and any inode that is left in the cache after > drop_caches is done will be a problem. For ex, in Android, drop_caches > will be used when switching work profiles. > > Signed-off-by: Sahitya Tummala <stummala@codeaurora.org> > --- > mm/vmscan.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index d96c547..b48926f 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -730,7 +730,7 @@ void drop_slab_node(int nid) > do { > freed += shrink_slab(GFP_KERNEL, nid, memcg, 0); > } while ((memcg = mem_cgroup_iter(NULL, memcg, NULL)) != NULL); > - } while (freed > 10); > + } while (freed != 0); > } Perhaps that is not enough, because the shrink may stop when scan count is less than SHRINK_BATCH. Pls. see do_shrink_slab. What about set shrinker->batch to 1 in this case ? Thanks Yafang
On Fri, May 24, 2019 at 01:36:01PM +0530, Sahitya Tummala wrote: > This is important for the scenario where FBE (file based encryption) > is enabled. With FBE, the encryption context needed to en/decrypt a file > will be stored in inode and any inode that is left in the cache after > drop_caches is done will be a problem. For ex, in Android, drop_caches > will be used when switching work profiles. > > Signed-off-by: Sahitya Tummala <stummala@codeaurora.org> Instead of making a change to vmscan.c, it's probably better to migrate to the new fscrypt key-management framework, which solves this problem with an explicit FS_IOC_REMOVE_ENCRYPTION_KEY ioctl. This allows the system to remove all inodes that were made available via a single key without having nuking all other inodes --- this would make it much faster after a user logs out of ChromeOS, for example: See: https://patchwork.kernel.org/patch/10952019/ - Ted
diff --git a/mm/vmscan.c b/mm/vmscan.c index d96c547..b48926f 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -730,7 +730,7 @@ void drop_slab_node(int nid) do { freed += shrink_slab(GFP_KERNEL, nid, memcg, 0); } while ((memcg = mem_cgroup_iter(NULL, memcg, NULL)) != NULL); - } while (freed > 10); + } while (freed != 0); } void drop_slab(void)
This is important for the scenario where FBE (file based encryption) is enabled. With FBE, the encryption context needed to en/decrypt a file will be stored in inode and any inode that is left in the cache after drop_caches is done will be a problem. For ex, in Android, drop_caches will be used when switching work profiles. Signed-off-by: Sahitya Tummala <stummala@codeaurora.org> --- mm/vmscan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)