On Thu, Dec 04, 2014 at 10:10:18PM +0200, Leonard Crestez wrote: > Yes, we are actually experiencing issues with this. We create lots of virtual > net_devices and routes, which means lots of percpu counters/pointers. In particular > we are getting worse performance than in older kernels because the net_device refcnt > is now a percpu counter. We could turn that back into a single integer but this > would negate an upstream optimization. > > We are working on top of linux_3.10. We already pulled some allocation optimizations. > At least for simple allocation patterns pcpu_alloc does not appear to be unreasonably > slow. Yeah, it got better for simpler patterns with Al's recent optimizations. Is your use case suffering heavily from percpu allocator overhead even with the recent optimizations? > Having a "properly scalable" percpu allocator would be quite nice indeed. Yeah, at the beginning, the expected (and existing at the time) use cases were fairly static and limited and the dumb scanning allocator worked fine. The usages grew a lot over the years, so, yeah, we prolly want something more scalable. I haven't seriously thought about the details yet tho. The space overhead is a lot higher than usual memory allocators, so we do want something which can pack things tighter. Given that there are a lot of smaller allocations anyway, maybe just converting the current implementation to bitmap based one is enough. If we set the min alignment at 4 bytes which should be fine, the bitmap overhead is slightly over 3% of the chunk size which should be fine. My hunch is that the current allocator is already using more than that on average. Are you interested in pursuing it? Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>