From: Christoph Hellwig <hch@lst.de>
To: ak@suse.d
Cc: akpm@osdl.org, linux-mm@kvack.org
Subject: numa api comments
Date: Mon, 19 Apr 2004 21:54:47 +0200 [thread overview]
Message-ID: <20040419195447.GA5900@lst.de> (raw)
(based on the code in 2.6.6-rc1-mm1)
- the
if (unlikely(order >= MAX_ORDER))
return NULL;
in alloc_pages_node and your new alloc_pages should probably move
into __alloc_pages, thus making alloc_pages_current as an entinity
of it's own superflous. It's naming is rather strange anyway.
- you add an extern for __alloc_page_vma but it doesn't seem to be
implemented at all
- alloc_page_vma arguments seems backwards. We usually have gfp_flags
arguments last which is kinda natural. Can we change the prototype to
alloc_page_vma(struct vm_area_struct *vma, unsigned long addr,
unsigned gfp_mask);
? Dito for sched.h, that one is used even more..
- could you please move the struct vm_area_struct forward delcaration
somewhere near the top of gfp.h (I usually prefer just below the
includes) ? In the middle of the prototypes it looks rather distracting.
- does mm.h as a widely-used header really need to include mempolicy.h?
AFAICS a forward-declaration of struct mempolicy would do it.
- can we please have a for_each_node() instead of mess like
for (nd = find_first_bit(nodes, MAX_NUMNODES);
nd < MAX_NUMNODES;
nd = find_next_bit(nodes, MAX_NUMNODES, 1+nd)) {
?
- swapin_readahead() seems to be used only in mm/memory.c, what about
making it static?
- alloc_page_interleave should probably reuse te existing
alloc_pages_node, ala:
static struct page *alloc_page_interleave(unsigned gfp, unsigned nid)
{
struct page *page = alloc_pages_node(nid, gfp_mask, 0);
if (page && page_zone(page) == zl->zones[0]) {
zl->zones[0]->pageset[get_cpu()].interleave_hit++;
put_cpu();
}
return page;
}
- the addition of mpol_set_vma_default() to gazillions of vma
initializations looking almost the same says we really want some
helper for it finally..
--
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:"aart@kvack.org"> aart@kvack.org </a>
next reply other threads:[~2004-04-19 19:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-19 19:54 Christoph Hellwig [this message]
2004-04-19 22:23 ` numa api comments Martin J. Bligh
2004-04-20 11:16 ` Paul Jackson
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=20040419195447.GA5900@lst.de \
--to=hch@lst.de \
--cc=ak@suse.d \
--cc=akpm@osdl.org \
--cc=linux-mm@kvack.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.