From: Nikolay Borisov <nborisov@suse.com>
To: Christoph Hellwig <hch@lst.de>, linux-xfs@vger.kernel.org
Cc: tom.leiming@gmail.com, vkuznets@redhat.com
Subject: Re: [PATCH v2] xfs: use a dedicated SLAB cache for sector sized buffer data
Date: Thu, 6 Dec 2018 19:22:09 +0200 [thread overview]
Message-ID: <52258a08-e79f-f52a-5062-6da805c268df@suse.com> (raw)
In-Reply-To: <20181205225147.12626-1-hch@lst.de>
On 6.12.18 г. 0:51 ч., Christoph Hellwig wrote:
> XFS currently uses kmalloc for buffers smaller than the page size to
> avoid wasting too much memory. But this can cause a problem with slub
> debugging turned on as the allocations might not be naturally aligned.
> On block devices that require sector size alignment this can lead to
> data corruption.
>
> Give that our smaller than page size buffers are always sector sized
> on a live file system, we can just create a kmem_cache with an
> explicitly specified alignment requirement for this case to fix this
> case without much effort.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>
> Changes since v1:
> - document the decision to use a single cache per file system in
> a comment
> - update the commit log a bit
>
> fs/xfs/xfs_buf.c | 23 +++++++++--------------
> fs/xfs/xfs_mount.h | 2 ++
> fs/xfs/xfs_super.c | 28 ++++++++++++++++++++++++++++
> 3 files changed, 39 insertions(+), 14 deletions(-)
>
> diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> index b21ea2ba768d..904d45f93ce7 100644
> --- a/fs/xfs/xfs_buf.c
> +++ b/fs/xfs/xfs_buf.c
> @@ -339,8 +339,10 @@ xfs_buf_free(
>
> __free_page(page);
> }
> - } else if (bp->b_flags & _XBF_KMEM)
> - kmem_free(bp->b_addr);
> + } else if (bp->b_flags & _XBF_KMEM) {
> + kmem_cache_free(bp->b_target->bt_mount->m_sector_cache,
> + bp->b_addr);
> + }
> _xfs_buf_free_pages(bp);
> xfs_buf_free_maps(bp);
> kmem_zone_free(xfs_buf_zone, bp);
> @@ -354,6 +356,7 @@ xfs_buf_allocate_memory(
> xfs_buf_t *bp,
> uint flags)
> {
> + struct xfs_mount *mp = bp->b_target->bt_mount;
> size_t size;
> size_t nbytes, offset;
> gfp_t gfp_mask = xb_to_gfp(flags);
> @@ -362,25 +365,17 @@ xfs_buf_allocate_memory(
> int error;
>
> /*
> - * for buffers that are contained within a single page, just allocate
> - * the memory from the heap - there's no need for the complexity of
> - * page arrays to keep allocation down to order 0.
> + * Use a special slab cache for sector sized buffers when sectors are
> + * small than a page to avoid wasting lots of memory.
nit: s/small/smaller/
<snip>
next prev parent reply other threads:[~2018-12-06 17:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-05 22:51 [PATCH v2] xfs: use a dedicated SLAB cache for sector sized buffer data Christoph Hellwig
2018-12-06 0:59 ` Dave Chinner
2018-12-06 12:51 ` Brian Foster
2018-12-06 15:17 ` Christoph Hellwig
2018-12-06 18:00 ` Darrick J. Wong
2018-12-06 21:38 ` Dave Chinner
2018-12-06 17:22 ` Nikolay Borisov [this message]
2018-12-06 18:11 ` Darrick J. Wong
2018-12-06 20:11 ` Christoph Hellwig
2018-12-06 20:26 ` Darrick J. Wong
2018-12-06 20:39 ` Brian Foster
2018-12-06 21:33 ` Dave Chinner
2018-12-07 10:14 ` Ming Lei
2018-12-07 15:21 ` Vitaly Kuznetsov
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=52258a08-e79f-f52a-5062-6da805c268df@suse.com \
--to=nborisov@suse.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