Re: [RFC] sparsemem patches (was nonlinear)

[Dave Hansen <haveblue@us.ibm.com>]

Andy Whitcroft wrote:
> Here are the current versions of my implmentation of
> CONFIG_SPARSEMEM; formerly CONFIG_NONLINEAR.  Mostly bug fixes to
> the alloc_remap() stuff and the conversion over to CONFIG_SPARSEMEM
> throughout.  The first few are esentially unchanged and only included
> for completeness.
> 
> As before they apply in numerical order.  This lot was diffed
> against 2.6.9 straight.
> 
> I take the view that the the breaking of V=P+c is an option
> to the memory model here.  So I'd expect to see something like
> CONFIG_SPARSEMEM_NONLINEAR or something.  So perhaps in the end this
> should be CONFIG_NONLINEAR if that happens.  But anyhow, changing
> its name now to SPARSEMEM will cirtainly help to reduce confusion :).

Thanks, Andy!

One thing that should simplify your code a bit are the no-buddy-bitmap 
patches which are sitting in -mm right now.  You might want to think 
about porting to -mm, it should reduce the total amount of code.

Also, after taking a bit more critical a look at the set, I'm not sure 
they're quite ready for merging yet.  There are still a pretty good 
number of #ifdefs

For instance, this:

+#ifdef HAVE_ARCH_ALLOC_REMAP
+		map = (unsigned long *) alloc_remap(pgdat->node_id,
+			bitmap_size);
+		if (!map)
+#endif
+			map = (unsigned long *)alloc_bootmem_node(pgdat,
+				bitmap_size);
+		zone->free_area[order].map = map;

Could all be solved by doing #ifdef in a header to declare alloc_remap() 
to return NULL if !HAVE_ARCH_ALLOC_REMAP.  In any case 
HAVE_ARCH_ALLOC_REMAP should be defined via a Kconfig file, not in a 
header.

Have you given any thought to using virt_to_page(page)->foo method to 
store section information instead of using page->flags?  It seems we're 
already sucking up page->flags left and right, and I'd hate to consume 
that many more.

Although simple arithmetically, the calculations for the flags shift 
does constitute a lot of code churn, and does add quite a bit of 
complexity.
--
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>