[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BC3F82A.20400@oracle.com>
Date: Mon, 12 Apr 2010 21:50:50 -0700
From: Yinghai <yinghai.lu@...cle.com>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
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 26/39] nobootmem: use lmb.default_alloc_limit in alloc_bootmem
path
On 04/12/2010 09:23 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2010-04-08 at 23:03 -0700, Yinghai Lu wrote:
>> Generic version __lmb_find_area() is going from high to low, and for 32bit
>> active_region for 32bit does include high pages
>>
>> need to replace the limit with lmb.default_alloc_limit, aka get_max_mapped()
>>
>> with this patch, x86 32bit could use generic version of __lmb_find_area()
>
> So you unconditionally add access to some lmb specific data structure to
> generic code ? That isn't going to work very well on archs that don't
> use lmb.
the whole function
#ifdef CONFIG_HAVE_LMB
u64 __init find_memory_core_early(int nid, u64 size, u64 align,
u64 goal, u64 limit)
{
int i;
/* Need to go over early_node_map to find out good range for node */
for_each_active_range_index_in_nid(i, nid) {
u64 addr;
u64 ei_start, ei_last;
ei_last = early_node_map[i].end_pfn;
ei_last <<= PAGE_SHIFT;
ei_start = early_node_map[i].start_pfn;
ei_start <<= PAGE_SHIFT;
addr = __lmb_find_area(ei_start, ei_last,
goal, limit, size, align);
if (addr == -1ULL)
continue;
return addr;
}
return -1ULL;
}
#endif
need to access early_node_map[], so leave the function here.
>
> Also, those things should be local to lmb_* anyways.
if you insist, could move it to lmb.c and use work_with_active_regions() around it.
YH
--
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