On Thu, 29 May 2008, Andrew Morton wrote: > > The per cpu memory use by subsystems is typically quite small. We already > > have an 8k limitation for percpu space for modules. And that does not seem > > to be a problem. > > eh? That's DEFINE_PERCPU memory, not alloc_pecpu() memory? No. The module subsystem has its own alloc_percpu subsystem that the cpu_alloc replaces. > > We could do that yes. > > Phew. But its going to be even more complicated and I have a hard time managing the complexity here. Could someone take pieces off my hand? > > But then per cpu data is not frequently allocated and freed. > > I think it is, in the TCP case. And that's the only one I looked at. Which tcp case? > Plus who knows what lies ahead of us? Well invariably we will end up with cpu area defragmentation.... Sigh. > I don't think there is presently any upper limit on alloc_percpu()? It > uses kmalloc() and kmalloc_node()? > > Even if there is some limit, is it an unfixable one? No there is no limit. It just wastes lots of space (pointer arrays, alignment etc) that we could use to configure sufficiently large per cpu areas. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
