Re: [PATCH -next 12/15] fs: dcache: move the sysctl into its own file

Jan Kara <[email protected]>
Newsgroups gmane.linux.kernel.lsm,gmane.linux.ports.sh.devel,gmane.linux.kernel,gmane.linux.file-systems,gmane.linux.kernel.mm,gmane.linux.nfs,gmane.linux.network
Message-ID <20240902110428.os726rhlt6y5i4ak@quack3>
On Mon 26-08-24 12:56:00, Kees Cook wrote:
> On Mon, Aug 26, 2024 at 08:04:46PM +0800, Kaixiong Yu wrote:
> > The sysctl_vfs_cache_pressure belongs to fs/dcache.c, move it to
> > its own file from kernel/sysctl.c. As a part of fs/dcache.c cleaning,
> > sysctl_vfs_cache_pressure is changed to a static variable, and export
> > vfs_pressure_ratio with EXPORT_SYMBOL_GPL to be used by other files.
> > And move the unneeded include(linux/dcache.h).
> > 
> > Signed-off-by: Kaixiong Yu <[email protected]>
> > ---
> >  fs/dcache.c            | 21 +++++++++++++++++++--
> >  include/linux/dcache.h |  7 +------
> >  kernel/sysctl.c        |  9 ---------
> >  3 files changed, 20 insertions(+), 17 deletions(-)
> > 
> > diff --git a/fs/dcache.c b/fs/dcache.c
> > index 1af75fa68638..8717d5026cda 100644
> > --- a/fs/dcache.c
> > +++ b/fs/dcache.c
> > @@ -73,8 +73,13 @@
> >   * If no ancestor relationship:
> >   * arbitrary, since it's serialized on rename_lock
> >   */
> > -int sysctl_vfs_cache_pressure __read_mostly = 100;
> > -EXPORT_SYMBOL_GPL(sysctl_vfs_cache_pressure);
> > +static int sysctl_vfs_cache_pressure __read_mostly = 100;
> > +
> > +unsigned long vfs_pressure_ratio(unsigned long val)
> > +{
> > +	return mult_frac(val, sysctl_vfs_cache_pressure, 100);
> > +}
> > +EXPORT_SYMBOL_GPL(vfs_pressure_ratio);
> 
> This was a static inline, but AFAICT it's only called through
> alloc_super() which is hardly "fast path". If this series gets another
> version it may be worth calling out this inline->out-of-line change in
> the commit log.
> 
> I don't think it's a blocker, but I'm not a VFS maintainer. :)

It's actually called from about 7 shrinkers of filesystem objects. They get
called relatively frequently during memory reclaim but I don't think a
function call is *that* expensive to matter in this case. Feel free to add:

Reviewed-by: Jan Kara <[email protected]>


								Honza
-- 
Jan Kara <[email protected]>
SUSE Labs, CR
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.