From: Mikulas Patocka <mpatocka@redhat.com>
To: Mel Gorman <mgorman@techsingularity.net>,
Andrew Morton <akpm@linux-foundation.org>,
Helge Deller <deller@gmx.de>,
"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
John David Anglin <dave.anglin@bell.net>,
linux-parisc@vger.kernel.org, linux-mm@kvack.org
Cc: 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: Sat, 6 Apr 2019 13:26:57 -0400 (EDT) [thread overview]
Message-ID: <alpine.LRH.2.02.1904061325170.1666@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1904061042490.9597@file01.intranet.prod.int.rdu2.redhat.com>
On Sat, 6 Apr 2019, Mikulas Patocka wrote:
> Hi
>
> The patch 1c30844d2dfe272d58c8fc000960b835d13aa2ac ("mm: reclaim small
> amounts of memory when an external fragmentation event occurs") breaks
> memory management on parisc.
>
> I have a parisc machine with 7GiB RAM, the chipset maps the physical
> memory to three zones:
> 0) Start 0x0000000000000000 End 0x000000003fffffff Size 1024 MB
> 1) Start 0x0000000100000000 End 0x00000001bfdfffff Size 3070 MB
> 2) Start 0x0000004040000000 End 0x00000040ffffffff Size 3072 MB
> (but it is not NUMA)
>
> With the patch 1c30844d2, the kernel will incorrectly reclaim the first
> zone when it fills up, ignoring the fact that there are two completely
> free zones. Basiscally, it limits cache size to 1GiB.
>
> For example, if I run:
> # dd if=/dev/sda of=/dev/null bs=1M count=2048
>
> - with the proper kernel, there should be "Buffers - 2GiB" when this
> command finishes. With the patch 1c30844d2, buffers will consume just 1GiB
> or slightly more, because the kernel was incorrectly reclaiming them.
>
> Mikulas
BTW, 3 years ago, there was exactly the same bug:
https://marc.info/?l=linux-kernel&m=146472966215941&w=2
Mikulas
next prev parent reply other threads:[~2019-04-06 17:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-06 15:20 Mikulas Patocka
2019-04-06 17:26 ` Mikulas Patocka [this message]
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
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=alpine.LRH.2.02.1904061325170.1666@file01.intranet.prod.int.rdu2.redhat.com \
--to=mpatocka@redhat.com \
--cc=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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox