From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xfs@vger.kernel.org, tom.leiming@gmail.com, vkuznets@redhat.com
Subject: Re: [PATCH] xfs: use a dedicated SLAB cache for sector sized buffer data
Date: Thu, 6 Dec 2018 09:31:39 +1100 [thread overview]
Message-ID: <20181205223139.GV6311@dastard> (raw)
In-Reply-To: <20181205215651.GA4033@lst.de>
On Wed, Dec 05, 2018 at 10:56:51PM +0100, Christoph Hellwig wrote:
> On Thu, Dec 06, 2018 at 08:50:00AM +1100, Dave Chinner wrote:
> > On Wed, Dec 05, 2018 at 09:20:23AM -0800, Christoph Hellwig wrote:
> > > XFS currently uses a slab allocator for buffers smaller than the page
> >
> > Currently uses heap allocated memory?
>
> Or kmalloc, yeah.
>
> > I thought you were looking at using the page_frag infrastructure for
> > this so we didn't need a slab per filesystem for this?
>
> I did look into it, but using page_frag for buffers creates an inherent
> memory leak given that page_frag never reuses a freed fragement. So
> until all fragments in a page are free all the others bits effectively
> leak, which is pretty bad on the buffer cache.
Ok, that's definitely a showstopper. I didn't notice this
behaviour when I had a quick look at it back when it was first
mentioned.
> > I think there's a problem with this code - we can have different
> > sector sizes for different devices in the filesystem. e.g. the log
> > can have a different sector size to the data device, and this may
> > matter for log recovery which does a lot of single sector IO.
>
> That's fine because log recovery is one I/O at a time, and we always
> free the current buffer before allocating the next one, so we'd waste
> the memory one way or another.
True. Can you mention this in the commit message so it gets recorded
with the change and doesn't get lost in the mists of time?
> > Hence I think this slab really needs to be managed as a property of
> > the of the buftarg rather than be a global property of the
> > xfs_mount. in most cases the log and data devices are the same
> > buftarg, but we should attempt to handle this special case
> > correctly...
>
> We could waste another slab cache on the block device, but as said
> we don't really save any memory by creating a new cache, we actually
> waste memory due to the overhead.
Slub will merge all into the one cache per sector size, anyway, so
there really isn't any wasted memory to speak of here.
Regardless, with a commit message update to explain why a single
cache is fine, then I'm happy with this.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-12-05 22:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-05 17:20 [PATCH] xfs: use a dedicated SLAB cache for sector sized buffer data Christoph Hellwig
2018-12-05 21:50 ` Dave Chinner
2018-12-05 21:56 ` Christoph Hellwig
2018-12-05 22:31 ` Dave Chinner [this message]
2018-12-05 22:33 ` Christoph Hellwig
2018-12-05 22:35 ` Darrick J. Wong
2018-12-05 22:51 ` Dave Chinner
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=20181205223139.GV6311@dastard \
--to=david@fromorbit.com \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
--cc=tom.leiming@gmail.com \
--cc=vkuznets@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox