All of lore.kernel.org
 help / color / mirror / Atom feed
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>

             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.