From: Joel Schopp <jschopp@austin.ibm.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: mike kravetz <kravetz@us.ibm.com>,
akpm@osdl.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
lhms-devel@lists.sourceforge.net
Subject: Re: [Lhms-devel] Re: [PATCH 5/8] Fragmentation Avoidance V17: 005_fallback
Date: Wed, 12 Oct 2005 12:29:35 -0500 [thread overview]
Message-ID: <434D47FF.1000602@austin.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0510121806550.9602@skynet>
> In reality, no and it would only happen if a caller had specified both
> __GFP_USER and __GFP_KERNRCLM in the call to alloc_pages() or friends. It
> makes *no* sense for someone to do this, but if they did, an oops would be
> thrown during an interrupt. The alternative is to get rid of this last
> element and put a BUG_ON() check before the spinlock is taken.
>
> This way, a stupid caller will damage the fragmentation strategy (which is
> bad). The alternative, the kernel will call BUG() (which is bad). The
> question is, which is worse?
>
If in the future we hypothetically have code that damages the fragmentation
strategy we want to find it sooner rather than never. I'd rather some kernels
BUG() than we have bugs which go unnoticed.
--
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:[~2005-10-12 17:28 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-11 15:12 [PATCH 0/8] Fragmentation Avoidance V17 Mel Gorman
2005-10-11 15:12 ` [PATCH 1/8] Fragmentation Avoidance V17: 001_antidefrag_flags Mel Gorman
2005-10-11 15:12 ` [PATCH 2/8] Fragmentation Avoidance V17: 002_usemap Mel Gorman
2005-10-13 13:56 ` Dave Hansen
2005-10-13 14:10 ` Mel Gorman
2005-10-13 14:18 ` Dave Hansen
2005-10-13 14:35 ` Mel Gorman
2005-10-16 20:44 ` Mel Gorman
2005-10-13 16:33 ` Joel Schopp
2005-10-11 15:12 ` [PATCH 3/8] Fragmentation Avoidance V17: 003_fragcore Mel Gorman
2005-10-11 15:12 ` [PATCH 4/8] Fragmentation Avoidance V17: 004_markfree Mel Gorman
2005-10-11 15:12 ` [PATCH 5/8] Fragmentation Avoidance V17: 005_fallback Mel Gorman
2005-10-12 16:43 ` mike kravetz
2005-10-12 17:21 ` Mel Gorman
2005-10-12 17:29 ` Joel Schopp [this message]
2005-10-14 5:12 ` [Lhms-devel] " Dave Hansen
2005-10-11 15:12 ` [PATCH 6/8] Fragmentation Avoidance V17: 006_largealloc_tryharder Mel Gorman
2005-10-13 19:07 ` Joel Schopp
2005-10-14 5:36 ` Dave Hansen
2005-10-11 15:12 ` [PATCH 7/8] Fragmentation Avoidance V17: 007_percpu Mel Gorman
2005-10-11 15:13 ` [PATCH 8/8] Fragmentation Avoidance V17: 008_stats Mel Gorman
2005-10-12 11:57 ` [Lhms-devel] " Dave Hansen
2005-10-12 12:19 ` Mel Gorman
2005-10-16 2:52 ` [PATCH 0/8] Fragmentation Avoidance V17 Paul Jackson
2005-10-16 11:59 ` Mel Gorman
2005-10-16 17:53 ` Paul Jackson
2005-10-16 18:03 ` 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=434D47FF.1000602@austin.ibm.com \
--to=jschopp@austin.ibm.com \
--cc=akpm@osdl.org \
--cc=kravetz@us.ibm.com \
--cc=lhms-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
/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