All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@lst.de>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 15/18] xfs: remove support for inlining data/extents into the inode fork
Date: Thu, 2 Nov 2017 15:08:00 -0700	[thread overview]
Message-ID: <20171102220800.GC4911@magnolia> (raw)
In-Reply-To: <20171102214321.GW5858@dastard>

On Fri, Nov 03, 2017 at 08:43:21AM +1100, Dave Chinner wrote:
> On Thu, Nov 02, 2017 at 12:26:34PM -0700, Darrick J. Wong wrote:
> > On Thu, Nov 02, 2017 at 07:57:25PM +0100, Christoph Hellwig wrote:
> > > On Tue, Oct 31, 2017 at 03:35:08PM -0700, Darrick J. Wong wrote:
> > > > Do you see any secondary effects, such as increased slab fragmentation
> > > > because of the extra kmem_allocs?  In general I think this should be ok,
> > > > I just worry slightly that whatever reason we had for having
> > > > if_inline_data is still around and will blow up in weird ways if we get
> > > > rid of it.
> > > 
> > > Why would we get much slab fragmentation?  The small slabs (16 or 32
> > > byte for those current users) have a huge turnover, so they generally
> > > aren't a majr problem.
> > 
> > I don't think they will be a serious problem either; this is just me
> > wondering why we had if_inline_data in the first place (now that we're
> > removing it).
> 
> Think back to ~1993 when XFS was first being implemented. State of
> the art was 100-150MHz CPUs, and so the cost of an allocation for
> every inode with a single data extent used a substantial fraction of
> the available CPU. And given that most files are a single extent,
> this was a worthwhile optimisation to minimise CPU overhead of the
> initial data read on a file.

Heh, that's what I expected was the reason.  Carry on, then. :)

> Nowdays, memory allocation costs less in terms of instructions than
> it did on Irix in 1993, and the CPUs are also a couple of orders of
> magnitudes faster. IOWs, the optimisation won't make as much
> difference to performance now as it did 20 years ago...
> 
> It's the same reason we have the data fork in the inode, but the
> attr fork is dynamically allocated - every inode has it's data fork
> referenced, but attr fork references are comparitively rare and
> generally not performance sensitive and so allocating the attr fork
> was a good trade-off between CPU overhead for those that needed
> attrs vs lower memory usage for the larger majority of users...

<nod>

--D

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-11-02 22:08 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-31 14:22 b+tree for the incore extent list Christoph Hellwig
2017-10-31 14:22 ` [PATCH 01/18] xfs: pass an on-disk extent to xfs_bmbt_validate_extent Christoph Hellwig
2017-10-31 17:53   ` Brian Foster
2017-10-31 21:15     ` Darrick J. Wong
2017-11-01 13:58       ` Brian Foster
2017-11-01 23:00         ` Darrick J. Wong
2017-11-02 11:57           ` Brian Foster
2017-11-02 16:05             ` Darrick J. Wong
2017-11-02 16:54               ` Brian Foster
2017-11-02 18:42                 ` Christoph Hellwig
2017-11-02 19:35                   ` Brian Foster
2017-11-02 23:45             ` Dave Chinner
2017-10-31 14:22 ` [PATCH 02/18] xfs: don't create overlapping extents in xfs_bmap_add_extent_delay_real Christoph Hellwig
2017-10-31 17:53   ` Brian Foster
2017-10-31 21:34   ` Darrick J. Wong
2017-10-31 14:22 ` [PATCH 03/18] xfs: treat idx as a cursor " Christoph Hellwig
2017-10-31 17:53   ` Brian Foster
2017-10-31 21:35   ` Darrick J. Wong
2017-10-31 14:22 ` [PATCH 04/18] xfs: treat idx as a cursor in xfs_bmap_add_extent_hole_delay Christoph Hellwig
2017-10-31 17:53   ` Brian Foster
2017-10-31 21:35   ` Darrick J. Wong
2017-10-31 14:22 ` [PATCH 05/18] xfs: treat idx as a cursor in xfs_bmap_add_extent_hole_real Christoph Hellwig
2017-10-31 17:53   ` Brian Foster
2017-10-31 21:35   ` Darrick J. Wong
2017-10-31 14:22 ` [PATCH 06/18] xfs: treat idx as a cursor in xfs_bmap_add_extent_unwritten_real Christoph Hellwig
2017-10-31 17:53   ` Brian Foster
2017-10-31 21:36   ` Darrick J. Wong
2017-10-31 14:22 ` [PATCH 07/18] xfs: treat idx as a cursor in xfs_bmap_del_extent_* Christoph Hellwig
2017-10-31 17:53   ` Brian Foster
2017-10-31 21:37   ` Darrick J. Wong
2017-10-31 14:22 ` [PATCH 08/18] xfs: treat idx as a cursor in xfs_bmap_collapse_extents Christoph Hellwig
2017-10-31 17:53   ` Brian Foster
2017-10-31 21:37   ` Darrick J. Wong
2017-10-31 14:22 ` [PATCH 09/18] xfs: allow unaligned extent records in xfs_bmbt_disk_set_all Christoph Hellwig
2017-10-31 21:34   ` Darrick J. Wong
2017-11-02 13:54   ` Brian Foster
2017-10-31 14:22 ` [PATCH 10/18] xfs: iterate over extents in xfs_iextents_copy Christoph Hellwig
2017-10-31 21:41   ` Darrick J. Wong
2017-11-02 13:54   ` Brian Foster
2017-10-31 14:22 ` [PATCH 11/18] xfs: iterate over extents in xfs_bmap_extents_to_btree Christoph Hellwig
2017-10-31 21:41   ` Darrick J. Wong
2017-11-02 13:54   ` Brian Foster
2017-10-31 14:22 ` [PATCH 12/18] xfs: introduce the xfs_iext_cursor abstraction Christoph Hellwig
2017-10-31 22:02   ` Darrick J. Wong
2017-11-02 18:49     ` Christoph Hellwig
2017-11-02 19:01       ` Darrick J. Wong
2017-11-02 19:11         ` Christoph Hellwig
2017-11-02 17:14   ` Brian Foster
2017-11-02 18:51     ` Christoph Hellwig
2017-11-02 19:36       ` Brian Foster
2017-11-03  7:26     ` Christoph Hellwig
2017-10-31 14:22 ` [PATCH 13/18] xfs: iterate backwards in xfs_reflink_cancel_cow_blocks Christoph Hellwig
2017-10-31 22:10   ` Darrick J. Wong
2017-10-31 14:22 ` [PATCH 14/18] xfs: simplify xfs_reflink_convert_cow Christoph Hellwig
2017-10-31 22:20   ` Darrick J. Wong
2017-11-02 18:56     ` Christoph Hellwig
2017-10-31 14:22 ` [PATCH 15/18] xfs: remove support for inlining data/extents into the inode fork Christoph Hellwig
2017-10-31 22:35   ` Darrick J. Wong
2017-11-02 18:57     ` Christoph Hellwig
2017-11-02 19:26       ` Darrick J. Wong
2017-11-02 21:43         ` Dave Chinner
2017-11-02 22:08           ` Darrick J. Wong [this message]
2017-10-31 14:22 ` [PATCH 16/18] xfs: use a b+tree for the in-core extent list Christoph Hellwig
2017-11-01 18:47   ` Darrick J. Wong
2017-11-02  0:16     ` Darrick J. Wong
2017-11-02  6:03       ` Christoph Hellwig
2017-11-02  0:14   ` Darrick J. Wong
2017-11-02 19:09     ` Christoph Hellwig
2017-10-31 14:22 ` [PATCH 17/18] xfs: remove the nr_extents argument to xfs_iext_insert Christoph Hellwig
2017-10-31 22:35   ` Darrick J. Wong
2017-10-31 14:22 ` [PATCH 18/18] xfs: remove the nr_extents argument to xfs_iext_remove Christoph Hellwig
2017-10-31 22:37   ` Darrick J. Wong
2017-11-01  3:08 ` b+tree for the incore extent list 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=20171102220800.GC4911@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --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 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.