Re: [PATCHSET] percpu: generalize first chunk allocators and improvelpage NUMA support

[Christoph Lameter]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/