From: Andi Kleen <ak@suse.de>
To: colpatch@us.ibm.com
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@digeo.com>,
"Martin J. Bligh" <mbligh@aracnet.com>,
lse-tech <lse-tech@lists.sourceforge.net>
Subject: Re: [Lse-tech] Re: [patch][rfc] Memory Binding (1/1)
Date: 02 Apr 2003 10:17:16 +0200 [thread overview]
Message-ID: <1049271440.30759.183.camel@averell> (raw)
In-Reply-To: <3E8A151A.1040800@us.ibm.com>
On Wed, 2003-04-02 at 00:39, Matthew Dobson wrote:
I'm not sure why you do this on shm segments only. Why not directly on
vmas ?
I'm considering to add a similar thing to the mm_struct to allow
processes to allocate on their "homenode" only. But I could also live
with it being per VMA.
In case of a large number of such bindings or nodes it may make sense
to cache and share the zone lists, but that can be probably left for a
future patch.
> +static inline struct page *__page_cache_alloc(struct address_space *x, int cold)
> +{
> + int gfp_mask;
> + struct zonelist *zonelist;
> +
> + gfp_mask = x->gfp_mask;
> + if (cold)
> + gfp_mask |= __GFP_COLD;
> + if (!x->binding)
> + zonelist = get_zonelist(gfp_mask);
> + else
> + zonelist = &x->binding->zonelist;
> +
> + return __alloc_pages(gfp_mask, 0, zonelist);
> +}
I would move a function of this size out of line. In fact i think it
should even in the non NUMA case be a simple function call with zonelist
getting evaluated out-of-line.
> +asmlinkage unsigned long sys_membind(unsigned long start, unsigned long len,
> + unsigned long *mask_ptr, unsigned int mask_len, unsigned long policy)
> +{
> + DECLARE_BITMAP(cpu_mask, NR_CPUS);
> + DECLARE_BITMAP(node_mask, MAX_NUMNODES);
> + struct vm_area_struct *vma = NULL;
> + struct address_space *mapping;
> + int error = 0;
> +
> + /* Deal with getting cpu_mask from userspace & translating to node_mask */
> + if (mask_len > NR_CPUS) {
> + error = -EINVAL;
> + goto out;
> + }
I don't like that check. It requires hardcoding NR_CPUs (which can be
variable!) in the application. It would be better to allow arbitary
length arguments, but only error when there is a bit set outside
NR_CPUS. Of course arbitary would be hard regarding the copy from user,
so perhaps use some very big limit (e.g. one page worth of bitmap)
> + CLEAR_BITMAP(cpu_mask, NR_CPUS);
> + CLEAR_BITMAP(node_mask, MAX_NUMNODES);
> + if (copy_from_user(cpu_mask, mask_ptr, (mask_len+7)/8)) {
> + error = -EFAULT;
> + goto out;
> + }
> + cpumask_to_nodemask(cpu_mask, node_mask);
> +
> + vma = find_vma(current->mm, start);
> + if (!(vma && vma->vm_file && vma->vm_ops &&
> + vma->vm_ops->nopage == shmem_nopage)) {
> + /* This isn't a shm segment. For now, we bail. */
> + printk("%s: Can only bind shm(em) segments for now!\n", __FUNCTION__);
Instead of __FUNCTION__ i would use current->comm here.
Or better perhaps just remove the error printks.
-Andi
prev parent reply other threads:[~2003-04-02 8:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-01 22:31 [patch][rfc] Memory Binding (0/1) Matthew Dobson
2003-04-01 22:39 ` [patch][rfc] Memory Binding (1/1) Matthew Dobson
2003-04-01 23:39 ` Andrew Morton
2003-04-02 2:42 ` Matthew Dobson
2003-04-02 20:43 ` Bryan Rittmeyer
2003-04-02 7:26 ` Christoph Hellwig
2003-04-02 8:17 ` Andi Kleen [this message]
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=1049271440.30759.183.camel@averell \
--to=ak@suse.de \
--cc=akpm@digeo.com \
--cc=colpatch@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=mbligh@aracnet.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