All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Matthew Wilcox <willy@infradead.org>,
	Stephen Brennan <stephen.s.brennan@oracle.com>,
	lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org,
	Gautham Ananthakrishna <gautham.ananthakrishna@oracle.com>,
	khlebnikov@yandex-team.ru
Subject: Re: [LSF/MM TOPIC] Better handling of negative dentries
Date: Wed, 23 Mar 2022 09:29:12 +1100	[thread overview]
Message-ID: <20220322222912.GF1609613@dread.disaster.area> (raw)
In-Reply-To: <Yjo9YrxU5SpydQKy@carbon.dhcp.thefacebook.com>

On Tue, Mar 22, 2022 at 02:19:30PM -0700, Roman Gushchin wrote:
> On Tue, Mar 22, 2022 at 08:41:56PM +0000, Matthew Wilcox wrote:
> > On Tue, Mar 15, 2022 at 01:56:18PM -0700, Roman Gushchin wrote:
> > > I’d be happy to join this discussion. And in my opinion it’s going
> > > beyond negative dentries: there are other types of objects which tend
> > > to grow beyond any reasonable limits if there is no memory pressure.
> > >
> > > A perfect example when it happens is when a machine is almost idle
> > > for some period of time. Periodically running processes creating
> > > various kernel objects (mostly vfs cache) which over time are filling
> > > significant portions of the total memory. And when the need for memory
> > > arises, we realize that the memory is heavily fragmented and it’s
> > > costly to reclaim it back.
> > 
> > When you say "vfs cache", do you mean page cache, inode cache, or
> > something else?
> 
> Mostly inodes and dentries, but also in theory some fs-specific objects
> (e.g. xfs implements nr_cached_objects/free_cached_objects callbacks).

Those aren't independent shrinkers - they are part of the superblock
shrinker.  XFS just uses these for background management of the VFS
inode cache footprint - vfs inodes live a bit longer than
->destroy_inode in XFS - so these callouts from the superblock
shrinker are really just part of the existing VFS inode cache
management.

> Also dentries, for example, can have attached kmalloc'ed areas if the
> length of the file's name is larger than x. And probably there are more
> examples of indirectly pinned objects.

The xfs buffer cache has slab allocated handles that can pin up to
64kB of pages each. The buffer cache can quickly grow to hold tens
of gigabytes of memory when you have filesystems with hundreds of
gigabytes of metadata in them (which are not that uncommon). It's
also not uncommon for the XFS buffer cache to consume more memory
than the VFS dentry and inode caches combined.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

      reply	other threads:[~2022-03-22 22:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-15 19:55 [LSF/MM TOPIC] Better handling of negative dentries Matthew Wilcox
2022-03-15 20:56 ` Roman Gushchin
2022-03-16  2:07   ` Gao Xiang
2022-03-16  2:52     ` Dave Chinner
2022-03-16  3:08       ` Gao Xiang
2022-03-22 15:08       ` Matthew Wilcox
2022-03-22 19:19         ` James Bottomley
2022-03-22 20:17           ` Colin Walters
2022-03-22 20:27             ` James Bottomley
2022-03-22 20:37             ` Matthew Wilcox
2022-03-22 21:08               ` Stephen Brennan
2022-03-29 15:24                 ` James Bottomley
2022-03-31 19:27                   ` Stephen Brennan
2022-04-01 15:45                     ` James Bottomley
2022-03-22 22:21         ` Dave Chinner
2022-03-22 20:41   ` Matthew Wilcox
2022-03-22 21:19     ` Roman Gushchin
2022-03-22 22:29       ` Dave Chinner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220322222912.GF1609613@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=gautham.ananthakrishna@oracle.com \
    --cc=khlebnikov@yandex-team.ru \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=roman.gushchin@linux.dev \
    --cc=stephen.s.brennan@oracle.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.