From: David Rientjes <rientjes@google.com>
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Mel Gorman <mel@csn.ul.ie>,
linux-mm@kvack.org, akpm@linux-foundation.org,
Nishanth Aravamudan <nacc@us.ibm.com>,
linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>,
Andy Whitcroft <apw@canonical.com>,
eric.whitney@hp.com
Subject: Re: [PATCH 4/6] hugetlb: introduce alloc_nodemask_of_node
Date: Thu, 3 Sep 2009 11:34:24 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.1.00.0909031122590.9055@chino.kir.corp.google.com> (raw)
In-Reply-To: <1251823334.4164.2.camel@useless.americas.hpqcorp.net>
On Tue, 1 Sep 2009, Lee Schermerhorn wrote:
> > > Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h
> > > ===================================================================
> > > --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/nodemask.h 2009-08-28 09:21:19.000000000 -0400
> > > +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h 2009-08-28 09:21:29.000000000 -0400
> > > @@ -245,18 +245,34 @@ static inline int __next_node(int n, con
> > > return min_t(int,MAX_NUMNODES,find_next_bit(srcp->bits, MAX_NUMNODES, n+1));
> > > }
> > >
> > > +#define init_nodemask_of_nodes(mask, node) \
> > > + nodes_clear(*(mask)); \
> > > + node_set((node), *(mask));
> > > +
> >
> > Is the done thing to either make this a static inline or else wrap it in
> > a do { } while(0) ? The reasoning being that if this is used as part of an
> > another statement (e.g. a for loop) that it'll actually compile instead of
> > throw up weird error messages.
>
> Right. I'll fix this [and signoff/review orders] next time [maybe last
> time?]. It occurs to me that I can also use this for
> huge_mpol_nodes_allowed(), so I'll move it up in the series and fix that
> [which you've already ack'd]. I'll wait a bit to hear from David before
> I respin.
>
I think it should be an inline function just so there's typechecking on
the first argument passed in (and so alloc_nodemask_of_node() below
doesn't get a NULL pointer dereference on node_set() if nmp can't be
allocated).
I've seen the issue about the signed-off-by/reviewed-by/acked-by order
come up before. I've always put my signed-off-by line last whenever
proposing patches because it shows a clear order in who gathered those
lines when submitting to -mm, for example. If I write
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: David Rientjes <rientjes@google.com>
it is clear that I cc'd Mel on the initial proposal. If it is the other
way around, for example,
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton...
then it indicates Andrew added the cc when merging into -mm. That's more
relevant when such a line is acked-by or reviewed-by since it is now
possible to determine who received such acknowledgement from the
individual and is responsible for correctly relaying it in the patch
submission.
If it's done this way, it indicates that whoever is signing off the patch
is responsible for everything above it. The type of line (signed-off-by,
reviewed-by, acked-by) is enough of an indication about the development
history of the patch, I believe, and it doesn't require specific ordering
to communicate (and the first line having to be a signed-off-by line isn't
really important, it doesn't replace the From: line).
It also appears to be how both Linus merges his own patches with Cc's.
> > > +/*
> > > + * returns pointer to kmalloc()'d nodemask initialized to contain the
> > > + * specified node. Caller must free with kfree().
> > > + */
> > > +#define alloc_nodemask_of_node(node) \
> > > +({ \
> > > + typeof(_unused_nodemask_arg_) *nmp; \
> > > + nmp = kmalloc(sizeof(*nmp), GFP_KERNEL); \
> > > + if (nmp) \
> > > + init_nodemask_of_nodes(nmp, (node)); \
> > > + nmp; \
> > > +})
> > > +
> >
--
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:[~2009-09-03 18:34 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-28 16:03 [PATCH 0/6] hugetlb: V5 constrain allocation/free based on task mempolicy Lee Schermerhorn
2009-08-28 16:03 ` [PATCH 1/6] hugetlb: rework hstate_next_node_* functions Lee Schermerhorn
2009-08-28 16:03 ` [PATCH 2/6] hugetlb: add nodemask arg to huge page alloc, free and surplus adjust fcns Lee Schermerhorn
2009-09-03 18:39 ` David Rientjes
2009-08-28 16:03 ` [PATCH 3/6] hugetlb: derive huge pages nodes allowed from task mempolicy Lee Schermerhorn
2009-09-01 14:47 ` Mel Gorman
2009-09-03 19:22 ` David Rientjes
2009-09-03 20:15 ` Lee Schermerhorn
2009-09-03 20:49 ` David Rientjes
2009-08-28 16:03 ` [PATCH 4/6] hugetlb: introduce alloc_nodemask_of_node Lee Schermerhorn
2009-09-01 14:49 ` Mel Gorman
2009-09-01 16:42 ` Lee Schermerhorn
2009-09-03 18:34 ` David Rientjes [this message]
2009-09-03 20:49 ` Lee Schermerhorn
2009-09-03 21:03 ` David Rientjes
2009-08-28 16:03 ` [PATCH 5/6] hugetlb: add per node hstate attributes Lee Schermerhorn
2009-09-01 15:20 ` Mel Gorman
2009-09-03 19:52 ` David Rientjes
2009-09-03 20:41 ` Lee Schermerhorn
2009-09-03 21:02 ` David Rientjes
2009-09-04 14:30 ` Lee Schermerhorn
2009-08-28 16:03 ` [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management Lee Schermerhorn
2009-09-03 20:07 ` David Rientjes
2009-09-03 21:09 ` Lee Schermerhorn
2009-09-03 21:25 ` David Rientjes
2009-09-08 10:44 ` Mel Gorman
2009-09-08 19:51 ` David Rientjes
2009-09-08 20:04 ` Mel Gorman
2009-09-08 20:18 ` David Rientjes
2009-09-08 21:41 ` Mel Gorman
2009-09-08 22:54 ` David Rientjes
2009-09-09 8:16 ` Mel Gorman
2009-09-09 20:44 ` David Rientjes
2009-09-10 12:26 ` Mel Gorman
2009-09-11 22:27 ` David Rientjes
2009-09-14 13:33 ` Mel Gorman
2009-09-14 14:15 ` Lee Schermerhorn
2009-09-14 15:41 ` Mel Gorman
2009-09-14 19:15 ` David Rientjes
2009-09-15 11:48 ` Mel Gorman
2009-09-14 19:14 ` David Rientjes
2009-09-14 21:28 ` David Rientjes
2009-09-16 10:21 ` Mel Gorman
2009-09-03 20:42 ` Randy Dunlap
2009-09-04 15:23 ` Lee Schermerhorn
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.DEB.1.00.0909031122590.9055@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=Lee.Schermerhorn@hp.com \
--cc=agl@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=apw@canonical.com \
--cc=eric.whitney@hp.com \
--cc=linux-mm@kvack.org \
--cc=linux-numa@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=nacc@us.ibm.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