Re: [RFC] sparsemem patches (was nonlinear)

Re: [RFC] sparsemem patches (was nonlinear)

[Dave Hansen]

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>

Re: [RFC] sparsemem patches (was nonlinear)

[Martin J. Bligh]

> 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.

It doesn't add any more. It reuses the existing overload space.
Only exception was if you wanted a billion piddly little segments on a 32bit.
Tough, don't do that ;-) For 64 bit, it's a non-issue.

M.

--
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>

Re: [RFC] sparsemem patches (was nonlinear)

[Andy Whitcroft]

Dave Hansen wrote:

> 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.

I've been meaning to bench those to see what effect losing the bitmaps 
has.  The difficult of the port to -mm due to the overlapping changes in 
the bitmaps has held me of that testing.  Sigh, going to have to bite 
the bullet.

> 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.

Yep, this is all a little slack and rubbish.  Basically cause I don't 
really think its the right way to do it.  I think we should really be 
putting the remap space into the bootmem allocators for each of the 
nodes.  Then either we are ok, cause the things we want allocated in 
there are allocated first and use it up.  We'd need the concept of 
falling back to node 0 when its out ... but.  In short, I'm still 
thinking about this part of the patch as its ugly as you noticed.

> 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.

As Martin indicates we don't use any more flags on the bit challenged 
arches where this would be an issue.  The little trick you used has some 
overhead to it, and current testing is showing an unexpected performance 
improvement with this stack.

> Although simple arithmetically, the calculations for the flags shift 
> does constitute a lot of code churn, and does add quite a bit of 
> complexity.

Yes, there is a lot of churn, though I hope the replacement 
infrastructure is more friendly to adding things to flags as needed.

-apw
--
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>

Re: [Lhms-devel] Re: [RFC] sparsemem patches (was nonlinear)

[Dave Hansen]

Andy Whitcroft wrote:
> Dave Hansen wrote:
>> 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.
> 
> As Martin indicates we don't use any more flags on the bit challenged 
> arches where this would be an issue. 

Could you explain a little bit how the section is encoded in there, and 
what kind of limits there are?  How many free bits do you need, and are 
there implications when it grows or shrinks as new PG_flags are added?

> The little trick you used has some 
> overhead to it, and current testing is showing an unexpected performance 
> improvement with this stack.

Does my little trick just have an anticipated performance impact, or a 
measured one?

--
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>