Skip to contentSkip to conversation

sparsemem patches (was nonlinear)

RFC Dave Hansen 3 participants 4 messages Oct 28, 2004 1 message not in the archive Memory management

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): 098973549.shadowen.org

Dave Hansen

author
#1 lore raw
Quoted 6 lines · Andy Whitcroft

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.

Quoted 8 lines

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#2 lore raw
Quoted 4 lines

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#3 lore raw
In reply to Dave Hansen
Quoted 1 line · Dave Hansen

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.

Quoted 13 lines

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:

(quoted diff) +8 -0
+#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;
Quoted 1 line

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.

Quoted 1 line

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.

Quoted 1 line

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

author
#4 lore raw
Quoted 4 lines · Andy Whitcroft
Quoted 1 line · Dave Hansen

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?

Quoted 1 line

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>