From: Christoph Hellwig <hch@lst.de>
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@lst.de>,
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: Wed, 5 Dec 2018 22:56:51 +0100 [thread overview]
Message-ID: <20181205215651.GA4033@lst.de> (raw)
In-Reply-To: <20181205215000.GU6311@dastard>
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.
> 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.
> 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.
next prev parent reply other threads:[~2018-12-05 21:56 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 [this message]
2018-12-05 22:31 ` Dave Chinner
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=20181205215651.GA4033@lst.de \
--to=hch@lst.de \
--cc=david@fromorbit.com \
--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 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.