From: "Darrick J. Wong" <djwong@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: chandan.babu@oracle.com, chandanrlinux@gmail.com,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH 4/4] xfs: use separate btree cursor slab for each btree type
Date: Mon, 27 Sep 2021 11:21:22 -0700 [thread overview]
Message-ID: <20210927182122.GT570615@magnolia> (raw)
In-Reply-To: <20210926004721.GD1756565@dread.disaster.area>
On Sun, Sep 26, 2021 at 10:47:21AM +1000, Dave Chinner wrote:
> On Thu, Sep 23, 2021 at 06:27:59PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> >
> > Now that we have the infrastructure to track the max possible height of
> > each btree type, we can create a separate slab zone for cursors of each
> > type of btree. For smaller indices like the free space btrees, this
> > means that we can pack more cursors into a slab page, improving slab
> > utilization.
> >
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> > fs/xfs/libxfs/xfs_btree.c | 12 ++++++------
> > fs/xfs/libxfs/xfs_btree.h | 9 +--------
> > fs/xfs/xfs_super.c | 33 ++++++++++++++++++++++++---------
> > 3 files changed, 31 insertions(+), 23 deletions(-)
> >
> >
> > diff --git a/fs/xfs/libxfs/xfs_btree.c b/fs/xfs/libxfs/xfs_btree.c
> > index 120280c998f8..3131de9ae631 100644
> > --- a/fs/xfs/libxfs/xfs_btree.c
> > +++ b/fs/xfs/libxfs/xfs_btree.c
> > @@ -26,7 +26,6 @@
> > /*
> > * Cursor allocation zone.
> > */
> > -kmem_zone_t *xfs_btree_cur_zone;
> > struct xfs_btree_cur_zone xfs_btree_cur_zones[XFS_BTNUM_MAX] = {
> > [XFS_BTNUM_BNO] = { .name = "xfs_alloc_btree_cur" },
> > [XFS_BTNUM_INO] = { .name = "xfs_ialloc_btree_cur" },
> > @@ -364,6 +363,7 @@ xfs_btree_del_cursor(
> > struct xfs_btree_cur *cur, /* btree cursor */
> > int error) /* del because of error */
> > {
> > + struct xfs_btree_cur_zone *bczone = &xfs_btree_cur_zones[cur->bc_btnum];
> > int i; /* btree level */
> >
> > /*
> > @@ -386,10 +386,10 @@ xfs_btree_del_cursor(
> > kmem_free(cur->bc_ops);
> > if (!(cur->bc_flags & XFS_BTREE_LONG_PTRS) && cur->bc_ag.pag)
> > xfs_perag_put(cur->bc_ag.pag);
> > - if (cur->bc_maxlevels > XFS_BTREE_CUR_ZONE_MAXLEVELS)
> > + if (cur->bc_maxlevels > bczone->maxlevels)
> > kmem_free(cur);
> > else
> > - kmem_cache_free(xfs_btree_cur_zone, cur);
> > + kmem_cache_free(bczone->zone, cur);
> > }
> >
> > /*
> > @@ -5021,12 +5021,12 @@ xfs_btree_alloc_cursor(
> > {
> > struct xfs_btree_cur *cur;
> > unsigned int maxlevels = xfs_btree_maxlevels(mp, btnum);
> > + struct xfs_btree_cur_zone *bczone = &xfs_btree_cur_zones[btnum];
> >
> > - if (maxlevels > XFS_BTREE_CUR_ZONE_MAXLEVELS)
> > + if (maxlevels > bczone->maxlevels)
> > cur = kmem_zalloc(xfs_btree_cur_sizeof(maxlevels), KM_NOFS);
> > else
> > - cur = kmem_cache_zalloc(xfs_btree_cur_zone,
> > - GFP_NOFS | __GFP_NOFAIL);
> > + cur = kmem_cache_zalloc(bczone->zone, GFP_NOFS | __GFP_NOFAIL);
>
> When will maxlevels ever be greater than bczone->maxlevels? Isn't
> the bczone->maxlevels case always supposed to be the tallest
> possible height for that btree?
It should never happen, provided that the maxlevels computation and
verification are all correct. I thought it was important to leave the
heap allocation in here as a fallback, since the consequence for getting
the size calculations wrong is corrupt kernel memory.
--D
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
next prev parent reply other threads:[~2021-09-27 18:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-24 1:27 [PATCHSET RFC v2 chandan 0/4] xfs: separate btree cursor slab zones Darrick J. Wong
2021-09-24 1:27 ` [PATCH 1/4] xfs: remove xfs_btree_cur.bc_blocklog Darrick J. Wong
2021-09-24 1:27 ` [PATCH 2/4] xfs: reduce the size of nr_ops for refcount btree cursors Darrick J. Wong
2021-09-24 1:27 ` [PATCH 3/4] xfs: check absolute maximum nlevels for each btree type Darrick J. Wong
2021-09-26 0:43 ` Dave Chinner
2021-09-27 18:17 ` Darrick J. Wong
2021-09-27 20:29 ` Darrick J. Wong
2021-09-27 21:57 ` Dave Chinner
2021-09-24 1:27 ` [PATCH 4/4] xfs: use separate btree cursor slab " Darrick J. Wong
2021-09-26 0:47 ` Dave Chinner
2021-09-27 18:21 ` Darrick J. Wong [this message]
2021-09-27 22:01 ` Dave Chinner
2021-10-12 18:49 ` 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:
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=20210927182122.GT570615@magnolia \
--to=djwong@kernel.org \
--cc=chandan.babu@oracle.com \
--cc=chandanrlinux@gmail.com \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.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 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).