archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <>
To: "Darrick J. Wong" <>
Subject: Re: [PATCH] xfs: fix I_DONTCACHE
Date: Tue, 24 Aug 2021 15:04:36 +1000	[thread overview]
Message-ID: <20210824050436.GL3657114@dread.disaster.area> (raw)
In-Reply-To: <20210824025841.GE12640@magnolia>

On Mon, Aug 23, 2021 at 07:58:41PM -0700, Darrick J. Wong wrote:
> On Tue, Aug 24, 2021 at 12:32:08PM +1000, Dave Chinner wrote:
> > From: Dave Chinner <>
> > 
> > Yup, the VFS hoist broke it, and nobody noticed. Bulkstat workloads
> > make it clear that it doesn't work as it should.
> Is there an easy way to test the dontcache behavior so that we don't
> screw this up again?
> /me's brain is fried, will study this in more detail in the morning.

Perhaps. We can measure how many xfs inodes are cached via the
filesystem stats e.g.

$ pminfo -t [number of vnodes not on free lists]
$ sudo grep xfs_inode /proc/slabinfo | awk '{ print $2 }'
$ pminfo -f
    value 243166

And so we should be able to run a bulkstat from fstests on a
filesystem with a known amount of files in it and measure the number
of cached inodes before/after...

I noticed this because I recently re-added the threaded per-ag
bulkstat scan to my scalability workload (via the xfs_io bulkstat
command) after I dropped it ages ago because per-ag threading of
fstests::src/bulkstat.c was really messy. It appears nobody has
been paying attention to bulkstat memory usage (and therefore
I_DONTCACHE behaviour) for some time....


Dave Chinner

  reply	other threads:[~2021-08-24  5:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-24  2:32 [PATCH] xfs: fix I_DONTCACHE Dave Chinner
2021-08-24  2:58 ` Darrick J. Wong
2021-08-24  5:04   ` Dave Chinner [this message]
2021-08-25 23:07 ` [RFC PATCH] xfs: test DONTCACHE behavior with the inode cache Darrick J. Wong
2021-08-26  0:47   ` Dave Chinner
2021-08-27  0:07     ` Darrick J. Wong
2021-08-25 23:09 ` [PATCH] xfs: fix I_DONTCACHE Darrick J. Wong

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:

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

  git send-email \
    --in-reply-to=20210824050436.GL3657114@dread.disaster.area \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).