* Re: [RFC] sparsemem patches (was nonlinear) [not found] <098973549.shadowen.org> @ 2004-10-28 16:04 ` Dave Hansen 2004-10-28 16:19 ` Martin J. Bligh 2004-10-28 16:32 ` Andy Whitcroft 0 siblings, 2 replies; 4+ messages in thread From: Dave Hansen @ 2004-10-28 16:04 UTC (permalink / raw) To: Andy Whitcroft; +Cc: lhms-devel, linux-mm 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> ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] sparsemem patches (was nonlinear) 2004-10-28 16:04 ` [RFC] sparsemem patches (was nonlinear) Dave Hansen @ 2004-10-28 16:19 ` Martin J. Bligh 2004-10-28 16:32 ` Andy Whitcroft 1 sibling, 0 replies; 4+ messages in thread From: Martin J. Bligh @ 2004-10-28 16:19 UTC (permalink / raw) To: Dave Hansen, Andy Whitcroft; +Cc: lhms-devel, linux-mm > 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> ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] sparsemem patches (was nonlinear) 2004-10-28 16:04 ` [RFC] sparsemem patches (was nonlinear) Dave Hansen 2004-10-28 16:19 ` Martin J. Bligh @ 2004-10-28 16:32 ` Andy Whitcroft 2004-10-28 16:52 ` [Lhms-devel] " Dave Hansen 1 sibling, 1 reply; 4+ messages in thread From: Andy Whitcroft @ 2004-10-28 16:32 UTC (permalink / raw) To: Dave Hansen; +Cc: lhms-devel, linux-mm 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> ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Lhms-devel] Re: [RFC] sparsemem patches (was nonlinear) 2004-10-28 16:32 ` Andy Whitcroft @ 2004-10-28 16:52 ` Dave Hansen 0 siblings, 0 replies; 4+ messages in thread From: Dave Hansen @ 2004-10-28 16:52 UTC (permalink / raw) To: Andy Whitcroft; +Cc: lhms-devel, linux-mm 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> ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-10-28 16:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <098973549.shadowen.org>
2004-10-28 16:04 ` [RFC] sparsemem patches (was nonlinear) Dave Hansen
2004-10-28 16:19 ` Martin J. Bligh
2004-10-28 16:32 ` Andy Whitcroft
2004-10-28 16:52 ` [Lhms-devel] " Dave Hansen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox