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>
next prev parent 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