All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christopher Lameter <cl@linux.com>
To: Dave Chinner <dchinner@redhat.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: Thu, 28 Dec 2017 18:19:15 -0600 (CST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1712281803130.26478@nuc-kabylake> (raw)
In-Reply-To: <20171228222419.GQ1871@rh>

On Fri, 29 Dec 2017, Dave Chinner wrote:

> 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...

Well this is a chance here to start an implementation since the radix tree
is being reworked anyways. This is not dealing with dentries and inodes
but it brings in the basic infrastructure into the slab allocators that
can then be used to add other slab caches. Same warnings were given to me
when we did page migration and it languished for 5 years.

I have not had time to really focus on memory management issues since I
left SGI about 9 years ago but it seems that I may now have the chance in
2018 to put a significant amount of time into making some progress.

Large memory in servers has become a significant problem for my employer
and the ability to allocate and manage contiguous memory blocks is
essential to preserve performance and avoid constant reboot. So I will be
looking for ways to address these issues. Maybe with a couple of
approaches.



--
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>

      reply	other threads:[~2017-12-29  0:19 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-27 22:06 [RFC 0/8] Xarray object migration V1 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
2017-12-29  0:19   ` Christopher Lameter [this message]

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=alpine.DEB.2.20.1712281803130.26478@nuc-kabylake \
    --to=cl@linux.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=dchinner@redhat.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 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.