[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1271135239.13059.69.camel@pasglop>
Date: Tue, 13 Apr 2010 15:07:19 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Yinghai <yinghai.lu@...cle.com>
Cc: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
David Miller <davem@...emloft.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 07/39] lmb: Add lmb_find_area()
On Mon, 2010-04-12 at 21:29 -0700, Yinghai wrote:
>
> > Haven't you noticed there's already way too many functions walking
> the
> > LMBs ? :-)
>
> x86 is using original lmb_reserve, lmb_free(), but have own version
> lmb_find_area(), and it will be dropped after
> more testing of generic version of lmb_find_area()
Do -not- add no APIs that are meant to be dropped. They never are in
practice. What I'm saying here is that the LMB code (including existing
stuff) could use some factoring in this area.
> >
> > I think the ones doing nid alloc could/should be also rewritten to
> use
> > one single low level __lmb_find_* no ?
>
> that nid_alloc() only has one user (sparc64).
>
> maybe could be replaced by lmd_find_area_node(), but need to make sure
> early_node_map[] is filled at first.
How does it work today ? IE. Which ever mechanism is used that works I
don't care but we shouldn't use 2 different ones.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists