From: Christoph Lameter <cl@linux.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>, Vlastimil Babka <vbabka@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
Linux-MM <linux-mm@kvack.org>,
Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: page_alloc: High-order per-cpu page allocator v3
Date: Mon, 28 Nov 2016 09:39:19 -0600 (CST) [thread overview]
Message-ID: <alpine.DEB.2.20.1611280934460.28989@east.gentwo.org> (raw)
In-Reply-To: <20161127131954.10026-1-mgorman@techsingularity.net>
On Sun, 27 Nov 2016, Mel Gorman wrote:
>
> SLUB has been the default small kernel object allocator for quite some time
> but it is not universally used due to performance concerns and a reliance
> on high-order pages. The high-order concerns has two major components --
> high-order pages are not always available and high-order page allocations
> potentially contend on the zone->lock. This patch addresses some concerns
> about the zone lock contention by extending the per-cpu page allocator to
> cache high-order pages. The patch makes the following modifications
Note that SLUB will only use high order pages when available and fall back
to order 0 if memory is fragmented. This means that the effect of this
patch is going to gradually vanish as memory becomes more and more
fragmented.
I think this patch is beneficial but we need to address long term the
issue of memory fragmentation. That is not only a SLUB issue but an
overall problem since we keep on having to maintain lists of 4k memory
blocks in variuos subsystems. And as memory increases these lists are
becoming larger and larger and more difficult to manage. Code complexity
increases and fragility too (look at transparent hugepages). Ultimately we
will need a clean way to manage the allocation and freeing of large
physically contiguous pages. Reserving memory at booting (CMA, giant
pages) is some sort of solution but this all devolves into lots of knobs
that only insiders know how to tune and an overall fragile solution.
--
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:[~2016-11-28 15:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-27 13:19 Mel Gorman
2016-11-28 11:00 ` Vlastimil Babka
2016-11-28 11:45 ` Mel Gorman
2016-11-30 8:55 ` Mel Gorman
2016-11-28 15:39 ` Christoph Lameter [this message]
2016-11-28 16:21 ` Mel Gorman
2016-11-28 16:38 ` Christoph Lameter
2016-11-28 18:47 ` Mel Gorman
2016-11-28 18:54 ` Christoph Lameter
2016-11-28 20:59 ` Vlastimil Babka
2016-11-28 19:54 ` Johannes Weiner
2016-11-30 12:40 ` Jesper Dangaard Brouer
2016-11-30 14:06 ` Mel Gorman
2016-11-30 15:06 ` Jesper Dangaard Brouer
2016-11-30 16:35 ` Mel Gorman
2016-12-01 17:34 ` Jesper Dangaard Brouer
2016-12-01 22:17 ` Paolo Abeni
2016-12-02 15:37 ` Jesper Dangaard Brouer
2016-12-02 15:44 ` Paolo Abeni
2016-11-30 13:05 ` Michal Hocko
2016-11-30 14:16 ` Mel Gorman
2016-11-30 14:59 ` Michal Hocko
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.1611280934460.28989@east.gentwo.org \
--to=cl@linux.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=vbabka@suse.cz \
/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