Messages in this thread | | | Subject | Re: [PATCH] x86_64: Make NR_IRQS configurable in Kconfig | From | Martin Schwidefsky <> | Date | Tue, 08 Aug 2006 10:17:53 +0200 |
| |
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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |