On 02/19/2010 07:14 AM, Christoph Lameter wrote: > On Thu, 18 Feb 2010, H. Peter Anvin wrote: > >>> As I have also repeatedly stated: Dynamic percpu data allocation when >>> onlining / offlining processors will complicate locking (cannot rely on >>> percpu be present anymore) and introduce numerous additional >>> hotplug notifiers into subsystems. >> >> I did state explicitly "on first up". Trying to free it would be >> insane. There are a couple of subsystems which are percpu memory >> pigs... so far it's not clear any of them actually matters in a >> production kernel. 60K * 16 phantom processors is still ~ 1 MB, which >> probably isn't enough to worry about but isn't great. > > The first up still means the addition of notifiers for subsystems that > have to initialilze their per cpu data and dealing with potential races > that would be caused by adding those. > Yes... it's ugly no matter which way we go (wasted memory vs. code complexity.) Wasted memory can be alleviated by minimizing the use of percpu memory; callbacks can be minimized by keeping a pattern buffer to which new allocations are initialized, and encouraging users to set things up so that that state is at least initially sufficient. We're probably okay for now (the only really heavy users of percpu are debugging at this point), and the other thing that might be worthwhile is if we can actually determine what platforms a "disabled CPU" could actually come to life. Hopefully disabled CPUs that aren't really available aren't *all* that common (it's not too common that people even turn off SMT, and if they know to do that they might be willing to add a kernel option if they care about the memory, too.) However, if percpu memory usage increases, it might be messy. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html