On Tue, 2006-08-08 at 07:14 +0200, Andi Kleen wrote: > > > > Drawback would be some more TLB misses. > > > > > > yup. On some (important) architectures - I'm not sure which architectures > > > do the bigpage-for-kernel trick. > > > > I looked at optimizing the per-cpu data accessors on PowerPC and only > > ever saw fractions of a percent change in overall performance, which > > says to me that we don't actually use per-cpu data all that much. So > > unless you make per-cpu data really really slow, I doubt that we'll > > see any significant performance difference. > > The main problem is that we would need a "vmalloc reserve first; allocate > pages > later" interface. On x86 it would be easy by just splitting up vmalloc/vmap a > bit > again. Does anybody else see problems with implementing that on any > other architecture?
"vmalloc reserve first; allocate pages later" would be a really nice feature. We could use this on s390 to implement the virtual mem_map array spanning the whole 64 bit address range (with holes in it). To make it perfect a "deallocate pages; keep vmalloc reserve" should be added, then we could free parts of the mem_map array again on hot memory remove. I don't see a problem for s390. -- blue skies, Martin. Martin Schwidefsky Linux for zSeries Development & Services IBM Deutschland Entwicklung GmbH "Reality continues to ruin my life." - Calvin. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
