From: Andrew Morton <akpm@linux-foundation.org>
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, linux-numa@vger.org, mel@csn.ul.ie,
nacc@us.ibm.com, rientjes@google.com, agl@us.ibm.com,
apw@canonical.com, eric.whitney@hp.com
Subject: Re: [RFC 2/3] hugetlb: derive huge pages nodes allowed from task mempolicy
Date: Wed, 1 Jul 2009 14:21:52 -0700 [thread overview]
Message-ID: <20090701142152.7f41fe70.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090630154818.1583.26154.sendpatchset@lts-notebook>
On Tue, 30 Jun 2009 11:48:18 -0400
Lee Schermerhorn <lee.schermerhorn@hp.com> wrote:
> [RFC 2/3] hugetlb: derive huge pages nodes allowed from task mempolicy
>
>
> ...
>
> +/**
> + * huge_mpol_nodes_allowed()
> + *
> + * Return a [pointer to a] nodelist for persistent huge page allocation
> + * based on the current task's mempolicy:
> + *
> + * If the task's mempolicy is "default" [NULL], just return NULL for
> + * default behavior. Otherwise, extract the policy nodemask for 'bind'
> + * or 'interleave' policy or construct a nodemask for 'preferred' or
> + * 'local' policy and return a pointer to a kmalloc()ed nodemask_t.
> + * It is the caller's responsibility to free this nodemask.
> + */
Comment purports to be kereldoc but doesn't look very kerneldoccy?
> +nodemask_t *huge_mpol_nodes_allowed(void)
> +{
> + nodemask_t *nodes_allowed = NULL;
> + struct mempolicy *mempolicy;
> + int nid;
> +
> + if (!current || !current->mempolicy)
> + return NULL;
> +
> + mpol_get(current->mempolicy);
> + nodes_allowed = kzalloc(sizeof(*nodes_allowed), GFP_KERNEL);
> + if (!nodes_allowed) {
> + printk(KERN_WARNING "Unable to allocate nodes allowed mask "
> + "for huge page allocation\nFalling back to default\n");
hm. If we're going to emit a diagnostic on behalf of userspace, it
would be best if that diagnostic were to contain sufficient information
for the identification of the failing application (pid and comm, for
example). Otherwise this mesasge would be a real head-scratcher on a
large and busy system.
> + goto out;
> + }
> +
> + mempolicy = current->mempolicy;
> + switch(mempolicy->mode) {
> + case MPOL_PREFERRED:
> + if (mempolicy->flags & MPOL_F_LOCAL)
> + nid = numa_node_id();
> + else
> + nid = mempolicy->v.preferred_node;
> + node_set(nid, *nodes_allowed);
> + break;
> +
> + case MPOL_BIND:
> + /* Fall through */
> + case MPOL_INTERLEAVE:
> + *nodes_allowed = mempolicy->v.nodes;
whitespace broke.
> + break;
> +
> + default:
> + BUG();
> + }
> +
> +out:
> + mpol_put(current->mempolicy);
> + return nodes_allowed;
> +}
--
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-07-01 21:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-30 15:47 [RFC 0/3] hugetlb: constrain allocation/free based on " Lee Schermerhorn
2009-06-30 15:47 ` [RFC 1/3] hugetlb: add nodemask arg to huge page alloc, free and surplus adjust fcns Lee Schermerhorn
2009-07-01 12:38 ` Mel Gorman
2009-07-01 13:00 ` Lee Schermerhorn
2009-07-01 21:17 ` Andrew Morton
2009-06-30 15:48 ` [RFC 2/3] hugetlb: derive huge pages nodes allowed from task mempolicy Lee Schermerhorn
2009-07-01 14:32 ` Mel Gorman
2009-07-01 16:19 ` Lee Schermerhorn
2009-07-01 18:29 ` Mel Gorman
2009-07-01 19:45 ` Lee Schermerhorn
2009-07-01 21:21 ` Andrew Morton [this message]
2009-06-30 15:48 ` [RFC 3/3] hugetlb: update hugetlb documentation for mempolicy based management Lee Schermerhorn
2009-07-01 17:28 ` [RFC 0/3] hugetlb: constrain allocation/free based on task mempolicy Lee Schermerhorn
2009-07-01 17:53 ` 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=20090701142152.7f41fe70.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=agl@us.ibm.com \
--cc=apw@canonical.com \
--cc=eric.whitney@hp.com \
--cc=lee.schermerhorn@hp.com \
--cc=linux-mm@kvack.org \
--cc=linux-numa@vger.org \
--cc=mel@csn.ul.ie \
--cc=nacc@us.ibm.com \
--cc=rientjes@google.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