linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Michal Hocko <mhocko@kernel.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Aruna Ramakrishna <aruna.ramakrishna@oracle.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jiri Slaby <jslaby@suse.cz>
Subject: Re: what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats
Date: Wed, 24 Aug 2016 23:01:43 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.20.1608242240460.1837@east.gentwo.org> (raw)
In-Reply-To: <20160824082057.GT2693@suse.de>

On Wed, 24 Aug 2016, Mel Gorman wrote:
> If/when I get back to the page allocator, the priority would be a bulk
> API for faster allocs of batches of order-0 pages instead of allocating
> a large page and splitting.
>

OMG. Do we really want to continue this? There are billions of Linux
devices out there that require a reboot at least once a week. This is now
standard with certain Android phones. In our company we reboot all
machines every week because fragmentation degrades performance
significantly. We need to finally face up to it and deal with the issue
instead of continuing to produce more half ass-ed solutions.

Managing memory in 4K chunks is not reasonable if you have
machines with terabytes of memory and thus billions of individual page
structs to manage. I/O devices are throttling because they cannot manage
so much meta data and we get grotesque devices.

The kernel needs an effective way to handle large contiguous memory. It
needs the ability to do effective defragmentation for that. And the way
forward has been clear also for awhile. All objects must be either
movable or be reclaimable so that things can be moved to allow contiguity
to be restored.


We have support for that for the page cache and interestingly enough for
CMA now. So this is gradually developing because it is necessary. We need
to go with that and provide a full fledged implementation in the kernel
that allows effective handling of large objects in the page allocator and
we need general logic in the kernel for effective handling of large
sized chunks of memory.

Lets stop churning tiny 4k segments in the world where even our cell
phones have capacities measured in Gigabytes which certainly then already
means millions of 4k objects whose management one by one is a drag on
performance and makes operating system coding extremely complex. The core
of Linux must support that for the future in which we will see even larger
memory capacities.

  reply	other threads:[~2016-08-25  4:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-17 18:20 [PATCH v3] mm/slab: Improve performance of gathering slabinfo stats Aruna Ramakrishna
2016-08-17 19:03 ` Eric Dumazet
2016-08-17 19:25   ` Aruna Ramakrishna
2016-08-18 11:52 ` Michal Hocko
2016-08-19  5:47   ` aruna.ramakrishna
2016-08-23  2:13   ` Joonsoo Kim
2016-08-23 15:38     ` what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats Michal Hocko
2016-08-23 15:54       ` what is the purpose of SLAB and SLUB Andi Kleen
2016-08-25  4:10         ` Christoph Lameter
2016-08-25  7:32           ` Michal Hocko
2016-08-25 19:49             ` Christoph Lameter
2016-08-24  1:15       ` what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats Joonsoo Kim
2016-08-24  8:05         ` Michal Hocko
2016-08-24  8:20       ` Mel Gorman
2016-08-25  4:01         ` Christoph Lameter [this message]
2016-08-25 10:07           ` Mel Gorman
2016-08-25 19:55             ` Christoph Lameter
2016-08-26 20:47               ` what is the purpose of SLAB and SLUB Andi Kleen
2016-08-29 13:44                 ` Michal Hocko
2016-08-29 14:49                   ` Christoph Lameter
2016-08-30  9:39               ` what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats Mel Gorman
2016-08-30 19:32                 ` Christoph 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=alpine.DEB.2.20.1608242240460.1837@east.gentwo.org \
    --to=cl@linux.com \
    --cc=akpm@linux-foundation.org \
    --cc=aruna.ramakrishna@oracle.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=mike.kravetz@oracle.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --subject='Re: what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).