On Tue, 30 Jun 2009, Ingo Molnar wrote: > > The difference between actual and possible cpus only has to be the > > number of processors that could be brought up later. In a regular > > system that is pretty much zero. In a fancy system with actual > > hotpluggable cpus there would be a difference but usually the > > number of hotpluggable cpus is minimal. > > You are arguing against the concept of the demand-allocation of > resources, and i dont think that technical argument can be won. I looked at allocating for online cpus only a couple of years back but at that per cpu state was kept for offlined cpus in per cpu areas. There are numerous assumptions in per cpu handling all over the kernel that a percpu area is always available. We successfully restricted it to only possible cpus. ACPI may be the worst offender there. If you can get all of that addressed then we can move to pure on demand allocation. Which also would complicate a per cpu memory allocator allocator. > Sure you dont have to demand-allocate if you know the demand > beforehand and can preallocate and size accordingly. Well you know the demand from the BIOS information. > But what if not? What if the kernel can run on up to 4096 CPUs and > runs on a big box. Why should a virtual machine have the illogical > choice between either wasting a lot of RAM preallocating stuff, or > limiting its own extendability. The kernel may be able to run on 4096 but the machines config information that is available via ACPI knows how many processors the machine we are booting on is able to add. > In other words: your proposed change in essence reduces the utility > of CPU hotplug. It's a bad idea. Change? I am talking about what is the case. -- 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