From: Dave Chinner <dchinner@redhat.com>
To: Christoph Lameter <cl@linux.com>
Cc: Matthew Wilcox <willy@infradead.org>,
linux-mm@kvack.org, Pekka Enberg <penberg@cs.helsinki.fi>,
akpm@linux-foundation.org, Mel Gorman <mel@skynet.ie>,
andi@firstfloor.org, Rik van Riel <riel@redhat.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC 0/8] Xarray object migration V1
Date: Fri, 29 Dec 2017 09:24:20 +1100 [thread overview]
Message-ID: <20171228222419.GQ1871@rh> (raw)
In-Reply-To: <20171227220636.361857279@linux.com>
On Wed, Dec 27, 2017 at 04:06:36PM -0600, Christoph Lameter wrote:
> This is a patchset on top of Matthew Wilcox Xarray code and implements
> object migration of xarray nodes. The migration is integrated into
> the defragmetation and shrinking logic of the slab allocator.
.....
> This is only possible for xarray for now but it would be worthwhile
> to extend this to dentries and inodes.
Christoph, you keep saying this is the goal, but I'm yet to see a
solution proposed for the atomic replacement of all the pointers to
an inode from external objects. An inode that has no active
references still has an awful lot of passive and internal references
that need to be dealt with.
e.g. racing page operations accessing mapping->host, the inode in
various lists (e.g. superblock inode list, writeback lists, etc),
the inode lookup cache(s), backpointers from LSMs, fsnotify marks,
crypto information, internal filesystem pointers (e.g. log items,
journal handles, buffer references, etc) and so on. And each
filesystem has a different set of passive references, too.
Oh, and I haven't even mentioned deadlocks yet, either. :P
IOWs, just saying "it would be worthwhile to extend this to dentries
and inodes" completely misrepresents the sheer complexity of doing
so. We've known that atomic replacement is the big problem for
defragging inodes and dentries since this work was started, what,
more than 10 years? And while there's been many revisions of the
core defrag code since then, there has been no credible solution
presented for atomic replacement of objects with complex external
references. This is a show-stopper for inode/dentry slab defrag, and
I don't see that this new patchset is any different...
Cheers,
Dave.
--
Dave Chinner
dchinner@redhat.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-12-28 22:24 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-27 22:06 Christoph Lameter
2017-12-27 22:06 ` [RFC 2/8] slub: Add defrag_ratio field and sysfs support Christoph Lameter
2017-12-30 6:20 ` Matthew Wilcox
2018-01-02 14:53 ` Christopher Lameter
2017-12-27 22:06 ` [RFC 3/8] slub: Add isolate() and migrate() methods Christoph Lameter
2017-12-30 6:42 ` Matthew Wilcox
2018-01-01 21:20 ` Matthew Wilcox
2018-01-02 14:56 ` Christopher Lameter
2018-01-02 14:55 ` Christopher Lameter
2017-12-27 22:06 ` [RFC 4/8] slub: Sort slab cache list and establish maximum objects for defrag slabs Christoph Lameter
2017-12-27 22:06 ` [RFC 5/8] slub: Slab defrag core Christoph Lameter
2017-12-27 22:06 ` [RFC 6/8] slub: Extend slabinfo to support -D and -F options Christoph Lameter
2017-12-27 22:06 ` [RFC 7/8] xarray: Implement migration function for objects Christoph Lameter
2017-12-27 22:06 ` [RFC 8/8] Add debugging output Christoph Lameter
2017-12-28 5:19 ` [RFC 0/8] Xarray object migration V1 Randy Dunlap
2017-12-28 14:57 ` Christopher Lameter
2017-12-28 17:18 ` James Bottomley
2017-12-28 17:33 ` Benjamin LaHaise
2017-12-28 17:40 ` James Bottomley
2017-12-28 19:17 ` Benjamin LaHaise
2017-12-28 20:00 ` James Bottomley
2017-12-28 20:33 ` Benjamin LaHaise
2017-12-28 22:24 ` Dave Chinner [this message]
2017-12-29 0:19 ` Christopher Lameter
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=20171228222419.GQ1871@rh \
--to=dchinner@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=cl@linux.com \
--cc=hch@lst.de \
--cc=linux-mm@kvack.org \
--cc=mel@skynet.ie \
--cc=penberg@cs.helsinki.fi \
--cc=riel@redhat.com \
--cc=willy@infradead.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