From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Helge Deller <deller@gmx.de>,
Mel Gorman <mgorman@techsingularity.net>,
Mikulas Patocka <mpatocka@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
John David Anglin <dave.anglin@bell.net>,
linux-parisc@vger.kernel.org, linux-mm@kvack.org,
Vlastimil Babka <vbabka@suse.cz>,
Andrea Arcangeli <aarcange@redhat.com>,
Zi Yan <zi.yan@cs.rutgers.edu>
Subject: Re: Memory management broken by "mm: reclaim small amounts of memory when an external fragmentation event occurs"
Date: Mon, 08 Apr 2019 12:44:48 -0700 [thread overview]
Message-ID: <1554752688.3634.6.camel@HansenPartnership.com> (raw)
In-Reply-To: <1aca1299-8713-3d54-7c5e-adf791509987@gmx.de>
On Mon, 2019-04-08 at 17:22 +0200, Helge Deller wrote:
> On 08.04.19 16:29, James Bottomley wrote:
> > On Mon, 2019-04-08 at 10:52 +0100, Mel Gorman wrote:
> > > First, if pa-risc is !NUMA then why are separate local ranges
> > > represented as separate nodes? Is it because of DISCONTIGMEM or
> > > something else? DISCONTIGMEM is before my time so I'm not
> > > familiar with it and I consider it "essentially dead" but the
> > > arch init code seems to setup pgdats for each physical contiguous
> > > range so it's a possibility. The most likely explanation is pa-
> > > risc does not have hardware with addressing limitations smaller
> > > than the CPUs physical address limits and it's possible to have
> > > more ranges than available zones but clarification would be nice.
> >
> > Let me try, since I remember the ancient history. In the early
> > days, there had to be a single mem_map array covering all of
> > physical memory. Some pa-risc systems had huge gaps in the
> > physical memory; I think one gap was somewhere around 1GB, so this
> > lead us to wasting huge amounts of space in mem_map on non-existent
> > memory. What CONFIG_DISCONTIGMEM did was allow you to represent
> > this discontinuity on a non-NUMA system using numa nodes, so we
> > effectively got one node per discontiguous range. It's hacky, but
> > it worked. I thought we finally got converted to sparsemem by the
> > NUMA people, but I can't find the commit.
>
> James, you tried once:
> https://patchwork.kernel.org/patch/729441/
Ah, so what I was remembering as someone else's problem was, in fact,
my problem? Hey, I should bottle my memory recall algorithms and sell
them as executive training courses.
> It seems we better should move over to sparsemem now?
I think so. The basics of the patch likely apply and hopefully in the
intervening 8 years some of the problems I identified have been fixed.
James
next prev parent reply other threads:[~2019-04-08 19:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-06 15:20 Memory management broken by "mm: reclaim small amounts of memory when an external fragmentation event occurs" Mikulas Patocka
2019-04-06 17:26 ` Mikulas Patocka
2019-04-08 9:52 ` Mel Gorman
2019-04-08 11:10 ` Mikulas Patocka
2019-04-08 12:54 ` Mel Gorman
2019-04-08 14:29 ` James Bottomley
2019-04-08 15:22 ` Helge Deller
2019-04-08 19:44 ` James Bottomley [this message]
2019-04-09 20:09 ` Helge Deller
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=1554752688.3634.6.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dave.anglin@bell.net \
--cc=deller@gmx.de \
--cc=linux-mm@kvack.org \
--cc=linux-parisc@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mpatocka@redhat.com \
--cc=vbabka@suse.cz \
--cc=zi.yan@cs.rutgers.edu \
/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.