From: Andrew Morton <akpm@linux-foundation.org>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Stuart Foster <smf.linux@ntlworld.com>,
linux-mm@kvack.org, bugzilla-daemon@bugzilla.kernel.org,
Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [Bug 42578] Kernel crash "Out of memory error by X" when using NTFS file system on external USB Hard drive
Date: Tue, 14 Feb 2012 12:37:12 -0800 [thread overview]
Message-ID: <20120214123712.77aa54ce.akpm@linux-foundation.org> (raw)
In-Reply-To: <20120214130955.GM17917@csn.ul.ie>
On Tue, 14 Feb 2012 13:09:55 +0000
Mel Gorman <mel@csn.ul.ie> wrote:
> Stuart Foster reported on https://bugzilla.kernel.org/show_bug.cgi?id=42578
> that copying large amounts of data from NTFS caused an OOM kill on 32-bit
> X86 with 16G of memory. Andrew Morton correctly identified that the problem
> was NTFS was using 512 blocks meaning each page had 8 buffer_heads in low
> memory pinning it.
>
> In the past, direct reclaim used to scan highmem even if the allocating
> process did not specify __GFP_HIGHMEM but not any more. kswapd no longer
> will reclaim from zones that are above the high watermark. The intention
> in both cases was to minimise unnecessary reclaim. The downside is on
> machines with large amounts of highmem that lowmem can be fully consumed
> by buffer_heads with nothing trying to free them.
>
> The following patch is based on a suggestion by Andrew Morton to extend
> the buffer_heads_over_limit case to force kswapd and direct reclaim to
> scan the highmem zone regardless of the allocation request or
> watermarks.
Seems reasonable, thanks.
I wonder if we really needed to change balance_pdgat(). The smaller we
can make profile of the special-case-hack the better. Perhaps poking
it into direct reclaim was sufficient?
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-02-14 20:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-42578-27@https.bugzilla.kernel.org/>
[not found] ` <201201180922.q0I9MCYl032623@bugzilla.kernel.org>
2012-01-19 20:24 ` [Bug 42578] Kernel crash "Out of memory error by X" when using NTFS file system on external USB Hard drive Andrew Morton
2012-02-10 16:37 ` Mel Gorman
2012-02-10 17:01 ` Rik van Riel
2012-02-14 12:17 ` Mel Gorman
2012-02-11 21:28 ` Stuart Foster
2012-02-14 13:09 ` Mel Gorman
2012-02-14 20:00 ` Christoph Lameter
2012-02-14 20:34 ` Andrew Morton
2012-02-14 20:42 ` Christoph Lameter
2012-02-14 20:37 ` Andrew Morton [this message]
2012-02-15 13:57 ` Mel Gorman
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=20120214123712.77aa54ce.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bugzilla-daemon@bugzilla.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=riel@redhat.com \
--cc=smf.linux@ntlworld.com \
/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.