Prev: nobootmem: use lmb.default_alloc_limit in alloc_bootmem path
Next: anonvma: when setting up page->mapping, we need to pick the _oldest_ anonvma
From: Benjamin Herrenschmidt on 13 Apr 2010 00:30 On Thu, 2010-04-08 at 23:03 -0700, Yinghai Lu wrote: > It can be used to find NODE_DATA for numa. > > Need to make sure early_node_map[] is filled before it is called, otherwise > it will fallback to lmb_find_area(), with node range. Isn't that more duplication from what's already in there for nid handling ? (Which btw may not be optimal, simply what I'm saying is that all that stuff should be factored). Cheers, Ben. > Signed-off-by: Yinghai Lu <yinghai(a)kernel.org> > --- > include/linux/lmb.h | 1 + > mm/lmb.c | 15 +++++++++++++++ > 2 files changed, 16 insertions(+), 0 deletions(-) > > diff --git a/include/linux/lmb.h b/include/linux/lmb.h > index 5dbc4ef..4078825 100644 > --- a/include/linux/lmb.h > +++ b/include/linux/lmb.h > @@ -91,6 +91,7 @@ void lmb_add_memory(u64 start, u64 end); > u64 __lmb_find_area(u64 ei_start, u64 ei_last, u64 start, u64 end, > u64 size, u64 align); > u64 lmb_find_area(u64 start, u64 end, u64 size, u64 align); > +u64 lmb_find_area_node(int nid, u64 start, u64 end, u64 size, u64 align); > > void lmb_to_bootmem(u64 start, u64 end); > struct range; > diff --git a/mm/lmb.c b/mm/lmb.c > index cf0f1c9..d3a58fb 100644 > --- a/mm/lmb.c > +++ b/mm/lmb.c > @@ -791,6 +791,21 @@ u64 __init __weak lmb_find_area(u64 start, u64 end, u64 size, u64 align) > return -1ULL; > } > /* > + * Need to call this function after lmb_register_active_regions, > + * so early_node_map[] is filled already. > + */ > +u64 __init lmb_find_area_node(int nid, u64 start, u64 end, u64 size, u64 align) > +{ > + u64 addr; > + addr = find_memory_core_early(nid, size, align, start, end); > + if (addr != -1ULL) > + return addr; > + > + /* Fallback, should already have start end within node range */ > + return lmb_find_area(start, end, size, align); > +} > + > +/* > * Finds an active region in the address range from start_pfn to last_pfn and > * returns its range in ei_startpfn and ei_endpfn for the lmb entry. > */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai on 13 Apr 2010 00:50 On 04/12/2010 09:18 PM, Benjamin Herrenschmidt wrote: > On Thu, 2010-04-08 at 23:03 -0700, Yinghai Lu wrote: >> It can be used to find NODE_DATA for numa. >> >> Need to make sure early_node_map[] is filled before it is called, otherwise >> it will fallback to lmb_find_area(), with node range. > > Isn't that more duplication from what's already in there for nid > handling ? (Which btw may not be optimal, simply what I'm saying is that > all that stuff should be factored). maybe could try to merge them later. or let sparc64 to use lmb_find_area_node()? YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on 10 May 2010 02:40
On Sat, 2010-05-08 at 08:17 -0700, Yinghai Lu wrote: > + * Need to call this function after lmb_register_active_regions, > + * so early_node_map[] is filled already. > + */ This is easily replaced by something simpler using my current WIP branch and its nid allocator. IE, You don't need to add find_memory_core_early(0 or any of that. It can be made a lot more simply. Cheers, Ben. > +u64 __init lmb_find_area_node(int nid, u64 start, u64 end, u64 size, > u64 align) > +{ > + u64 addr; > + addr = find_memory_core_early(nid, size, align, start, end); > + if (addr != LMB_ERROR) > + return addr; > + > + /* Fallback, should already have start end within node range > */ > + return lmb_find_area(start, end, size, align); > +} > + -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |