From: Paul Jackson <pj@sgi.com>
To: Joel Schopp <jschopp@austin.ibm.com>
Cc: haveblue@us.ibm.com, mrmacman_g4@mac.com, akpm@osdl.org,
lhms-devel@lists.sourceforge.net, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, mel@csn.ul.ie, kravetz@us.ibm.com
Subject: Re: [Lhms-devel] Re: [PATCH 1/9] add defrag flags
Date: Tue, 27 Sep 2005 14:23:55 -0700 [thread overview]
Message-ID: <20050927142355.232f6e95.pj@sgi.com> (raw)
In-Reply-To: <4339B2F6.1070806@austin.ibm.com>
> But for now I'm going to leave it __GFP_USER.
Well, then, at least fix the comment, from the rather oddly phrased:
#define __GFP_USER 0x40000u /* User is a userspace user */
to something more accurate such as:
#define __GFP_USER 0x40000u /* User and other really easily reclaimed pages */
And consider adding a comment to its use in fs/buffer.c, where marking
a page obviously destined for kernel space __GFP_USER seems strange.
I doubt I will be the last person to look at the line of code and
scratch my head.
Nice clear simple names such as __GFP_USER (only a kernel hacker would
say that ;) should not be used if they are a flat out lie. Better to
use some tongue twister acronym, such as
#define__GFP_RRE_RCLM 0x40000u /* Really Really Easy ReCLaiM (user, buffer) */
so that people don't think they know what something means when they don't.
And the one thing you could say that's useful in this name, that it has
something to do with the reclaim mechanism, is missing - no 'RCLM' in it.
Roses may smell sweet by other names, but kernel names for things do
matter. Unlike classic flowers, we have an awful lot of colorless,
ordorless stuff in there that no one learns about in childhood (Linus's
child notwithstanding ;). We desparately need names to tell the
essentials, and not lie. __GFP_USER does neither.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
--
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-09-27 21:23 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-26 20:01 [PATCH 0/9] fragmentation avoidance Joel Schopp
2005-09-26 20:03 ` [PATCH 1/9] add defrag flags Joel Schopp
2005-09-27 0:16 ` Kyle Moffett
2005-09-27 0:24 ` Dave Hansen
2005-09-27 0:43 ` Kyle Moffett
2005-09-27 5:44 ` Paul Jackson
2005-09-27 13:34 ` Mel Gorman
2005-09-27 16:26 ` [Lhms-devel] " Paul Jackson
2005-09-27 18:38 ` Joel Schopp
2005-09-27 19:30 ` Paul Jackson
2005-09-27 21:00 ` [Lhms-devel] " Joel Schopp
2005-09-27 21:23 ` Paul Jackson [this message]
2005-09-27 22:03 ` Joel Schopp
2005-09-27 22:45 ` Paul Jackson
2005-09-26 20:05 ` [PATCH 2/9] declare defrag structs Joel Schopp
2005-09-26 20:06 ` [PATCH 3/9] initialize defrag Joel Schopp
2005-09-26 20:09 ` [PATCH 4/9] defrag helper functions Joel Schopp
2005-09-26 22:29 ` Alex Bligh - linux-kernel
2005-09-27 16:08 ` Joel Schopp
2005-09-26 20:11 ` [PATCH 5/9] propagate defrag alloc types Joel Schopp
2005-09-26 20:13 ` [PATCH 6/9] fragmentation avoidance core Joel Schopp
2005-09-26 20:14 ` [PATCH 7/9] try harder on large allocations Joel Schopp
2005-09-27 7:21 ` Coywolf Qi Hunt
2005-09-27 16:17 ` Joel Schopp
2005-09-26 20:16 ` [PATCH 8/9] defrag fallback Joel Schopp
2005-09-26 20:17 ` [PATCH 9/9] free memory is user reclaimable Joel Schopp
2005-09-26 20:19 ` [PATCH 10/9] percpu splitout Joel Schopp
2005-09-26 21:49 ` [Lhms-devel] [PATCH 0/9] fragmentation avoidance Joel Schopp
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=20050927142355.232f6e95.pj@sgi.com \
--to=pj@sgi.com \
--cc=akpm@osdl.org \
--cc=haveblue@us.ibm.com \
--cc=jschopp@austin.ibm.com \
--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 \
--cc=mrmacman_g4@mac.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox