linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Christopher Lameter <cl@linux.com>,
	Michal Hocko <mhocko@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Vlastimil Babka <vbabka@suse.cz>, Mel Gorman <mgorman@suse.de>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-doc@vger.kernel.org
Subject: Re: [patch 1/2] mm, page_alloc: extend kernelcore and movablecore for percent
Date: Thu, 15 Feb 2018 16:45:02 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.10.1802151638510.50948@chino.kir.corp.google.com> (raw)
In-Reply-To: <20180215204817.GB22948@bombadil.infradead.org>

On Thu, 15 Feb 2018, Matthew Wilcox wrote:

> What I was proposing was an intermediate page allocator where slab would
> request 2MB for its own uses all at once, then allocate pages from that to
> individual slabs, so allocating a kmalloc-32 object and a dentry object
> would result in 510 pages of memory still being available for any slab
> that needed it.
> 

A type of memory arena built between the page allocator and slab 
allocator.

The issue that I see with this is eventually there's going to be low on 
memory situations where memory needs to be reclaimed from these arena 
pages.  We can free individual pages back to the buddy allocator, but have 
no control over whether an entire pageblock can be freed back.  So now we 
have MIGRATE_MOVABLE or MIGRATE_UNMOVABLE pageblocks with some user pages 
and some slab pages, and we've reached the same fragmentation issue in a 
different way.  After that, it will become more difficult for the slab 
allocator to request a page of pageblock_order.

Other than the stranding issue of MIGRATE_UNMOVABLE pages on pcps, the 
page allocator currently does well in falling back to other migratetypes 
but there isn't any type of slab reclaim or defragmentation done in the 
background to try to free up as much memory from that 
now-MIGRATE_UNMOVABLE pageblock as possible.  We have patches that do 
that, but as I mentioned before it can affect the performance of the page 
allocator because it drains pcps on fallback and it does kcompactd 
compaction in the background even if you don't need order-9 memory later 
(or you've defragmented needlessly when more slab is just going to be 
allocated anyway).

--
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:[~2018-02-16  0:45 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-13  0:24 David Rientjes
2018-02-13  0:24 ` [patch 2/2] mm, page_alloc: move mirrored_kernelcore to __meminitdata David Rientjes
2018-02-13 23:46 ` [patch 1/2] mm, page_alloc: extend kernelcore and movablecore for percent Andrew Morton
2018-02-13 23:55   ` David Rientjes
2018-02-14  1:14     ` Andrew Morton
2018-02-14  0:37 ` Mike Kravetz
2018-02-14  0:53   ` David Rientjes
2018-02-14  1:00     ` [patch -mm] mm, page_alloc: extend kernelcore and movablecore for percent fix David Rientjes
2018-02-14  1:10       ` Mike Kravetz
2018-02-14  9:59 ` [patch 1/2] mm, page_alloc: extend kernelcore and movablecore for percent Michal Hocko
2018-02-14 10:28   ` David Rientjes
2018-02-15 14:45     ` Michal Hocko
2018-02-15 15:11       ` Matthew Wilcox
2018-02-15 15:49         ` Christopher Lameter
2018-02-15 20:14           ` Matthew Wilcox
2018-02-16 15:41             ` Christopher Lameter
2018-02-15 20:48           ` Matthew Wilcox
2018-02-16  0:45             ` David Rientjes [this message]
2018-02-16 15:44             ` Christopher Lameter
2018-02-16 16:01               ` Matthew Wilcox
2018-02-16 16:08                 ` Christopher Lameter
2018-02-16 17:09                   ` Matthew Wilcox
2018-02-15 20:47       ` David Rientjes

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.10.1802151638510.50948@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=vbabka@suse.cz \
    --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