From: Dave Hansen <dave@linux.vnet.ibm.com>
To: paul.szabo@sydney.edu.au
Cc: 695182@bugs.debian.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC] Reproducible OOM with partial workaround
Date: Thu, 10 Jan 2013 17:26:04 -0800 [thread overview]
Message-ID: <50EF6A2C.7070606@linux.vnet.ibm.com> (raw)
In-Reply-To: <201301110046.r0B0k6lR024284@como.maths.usyd.edu.au>
On 01/10/2013 04:46 PM, paul.szabo@sydney.edu.au wrote:
>> Your configuration has never worked. This isn't a regression ...
>> ... does not mean that we expect it to work.
>
> Do you mean that CONFIG_HIGHMEM64G is deprecated, should not be used;
> that all development is for 64-bit only?
My last 4GB laptop had a 1GB hole and needed HIGHMEM64G since it had RAM
at 0->5GB. That worked just fine, btw. The problem isn't with
HIGHMEM64G itself.
I'm not saying HIGHMEM64G is inherently bad, just that it gets gradually
worse and worse as you add more RAM. I don't believe 64GB of RAM has
_ever_ been booted on a 32-bit kernel without either violating the ABI
(3GB/1GB split) or doing something that never got merged upstream (that
4GB/4GB split, or other fun stuff like page clustering).
> I find it puzzling that there seems to be a sharp cutoff at 32GB RAM,
> no problem under but OOM just over; whereas I would have expected
> lowmem starvation to be gradual, with OOM occuring much sooner with
> 64GB than with 34GB. Also, the kernel seems capable of reclaiming
> lowmem, so I wonder why does that fail just over the 32GB threshhold.
> (Obviously I have no idea what I am talking about.)
It _is_ puzzling. It isn't immediately obvious to me why the slab that
you have isn't being reclaimed. There might, indeed, be a fixable bug
there. But, there are probably a bunch more bugs which will keep you
from having a nice, smoothly-running system, mostly those bugs have not
had much attention in the 10 years or so since 64-bit x86 became
commonplace. Plus, even 10 years ago, when folks were working on this
actively, we _never_ got things running smoothly on 32GB of RAM. Take a
look at this:
http://support.bull.com/ols/product/system/linux/redhat/help/kbf/g/inst/PrKB11417
You are effectively running the "SMP kernel" (hugemem is a completely
different beast).
I had a 32GB i386 system. It was a really, really fun system to play
with, and its never-ending list of bugs helped keep me employed for
several years. You don't want to unnecessarily inflict that pain on
yourself, really.
--
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:[~2013-01-11 1:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-10 21:58 [RFC] Reproducible OOM with partial workaround paul.szabo
2013-01-10 23:12 ` Dave Hansen
2013-01-11 0:46 ` paul.szabo
2013-01-11 1:26 ` Dave Hansen [this message]
2013-01-11 1:46 ` paul.szabo
2013-01-11 8:01 ` Andrew Morton
2013-01-11 8:30 ` Simon Jeons
2013-01-11 11:51 ` paul.szabo
2013-01-11 20:31 ` Andrew Morton
2013-01-12 3:24 ` paul.szabo
2013-01-11 16:04 ` Dave Hansen
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=50EF6A2C.7070606@linux.vnet.ibm.com \
--to=dave@linux.vnet.ibm.com \
--cc=695182@bugs.debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=paul.szabo@sydney.edu.au \
/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;
as well as URLs for NNTP newsgroup(s).