Comment 15 for bug 1543149

I have issues with the fix.

Firstly, and perhaps the most problematic point: it assumes the non-OpenStack consumption of pages ('reserved' pages, though they're not 'reserved' in the same sense as normal memory is 'reserved') is static. There's no reason to believe that's true. This isn't like the reserved memory in normal memory allocation, remember; that tracks system available memory as well, and this doesn't track available hugepages. In this instance it's quite possible to have other processes consuming hugepages over time, and it's also possible to configure the kernel to break up hugepages if necessary, so it's a lot more like normal memory than a countable resource such as number of cores or PCI devices.

Secondly, why calculate total-reserved in the scheduler and not on the compute host? The scheduler needs to know free pages, it doesn't need to know all the information returned. If it was told *only* the number of free pages I think we'd have more flexibility to improve the scheduler code and the compute node, and improve them independently, so it's more future proof. Telling it the number of reserved pages can't help it.

Aside from that, the total number of hugepages is not fixed, as the pre-patch version of the code assumes. It can be changed after initial deployment, but for some reason has been treated as a fixed feature of the system like the number of cores, sockets or CPU flags. Not a criticism of this bug but another flag pointing that a rethink might be in order.