Skip to contentSkip to conversation

increase ia64 static per cpu area

RFC In review Luck, Tony 2 participants 3 messages Jul 26, 2010 – Jul 28, 2010

lore
Share & tools
lore

Luck, Tony

author
#0 lore raw

RFC 1/1 increase ia64 static per cpu area

I've been trying to avoid this for a long time ... but per-cpu space has slowly been growing. Tejun has some patches in linux-next that pre-reserve some space (PERCPU_DYNAMIC_EARLY_SIZE) for use before slab comes online ... and this pushes ia64 above the 64K current limit on static percpu space.

I could probably squeeze it back under (we are only over by 512 bytes). But I don't think that I'll be able to squeeze it down enough to build a comfortable breathing space - and I don't want to keep nibbling off a dozen bytes here and there every time some generic code bumps us back over the limit.

Next available supported page size is 256K ... so we have to quadruple the available space - a bigger jump than I'd like. But perhaps it will be enough to last a few more years before it needs to be increased again.

---

arch/ia64/include/asm/page.h +1 -1
index 5f271bc..41b6d31 100644
@@ -41,7 +41,7 @@
 #define PAGE_SIZE		(__IA64_UL_CONST(1) << PAGE_SHIFT)
 #define PAGE_MASK		(~(PAGE_SIZE - 1))
 
-#define PERCPU_PAGE_SHIFT	16	/* log2() of max. size of per-CPU area */
+#define PERCPU_PAGE_SHIFT	18	/* log2() of max. size of per-CPU area */
 #define PERCPU_PAGE_SIZE	(__IA64_UL_CONST(1) << PERCPU_PAGE_SHIFT)
 
 
Acked-by on v1 1/1
#1 lore raw

Hello,

Quoted 5 lines · Tony

I've been trying to avoid this for a long time ... but per-cpu space has slowly been growing. Tejun has some patches in linux-next that pre-reserve some space (PERCPU_DYNAMIC_EARLY_SIZE) for use before slab comes online ... and this pushes ia64 above the 64K current limit on static percpu space.

Yeah, more stuff are moving to percpu area. I'm thinking about increasing PERCPU_DYNAMIC_RESERVE too as it's overflowing in most common cases now, but it's not really a bad thing tho. Many of those used to use NR_CPUS allocations instead so overall I don't think we're wasting memory.

Quoted 11 lines

I could probably squeeze it back under (we are only over by 512 bytes). But I don't think that I'll be able to squeeze it down enough to build a comfortable breathing space - and I don't want to keep nibbling off a dozen bytes here and there every time some generic code bumps us back over the limit.

Next available supported page size is 256K ... so we have to quadruple the available space - a bigger jump than I'd like. But perhaps it will be enough to last a few more years before it needs to be increased again.

I suppose this would go through ia64 tree?

Thank you.

Signature · 1 line
tejun
author
#2 lore raw
In reply to Luck, Tony
Quoted 1 line

Thanks.

Quoted 1 line

I suppose this would go through ia64 tree?

Yes. I've just added it to my "test" tree, so it will be merged into the next linux-next.

I'm assuming your percpu changes are planned for the next merge window. I'll push this
to Linus then.

-Tony