On Thu, 22 Oct 2009, Ben Hutchings wrote: > The Debian kernel team received a request to enable this config option > in our packaged kernels for x86-64, with reference to > Documentation/x86/x86_64/fake-numa-for-cpusets. This document seems to > encourage the use this option in production. However, the Kconfig help > text for this says (as it has done from the beginning of git history): > > Enable NUMA emulation. A flat machine will be split > into virtual nodes when booted with "numa=fake=N", where N is the > number of nodes. This is only useful for debugging. > > Please could you clarify whether you think this is really suitable for > production use, in particular whether it would be sane to enable the > config option in a distribution kernel? >
It's definitely sane to enable it because all it does is add init code that will be freed after boot even if NUMA emulation is in use. The vast majority of the time, it's used for debugging VM code as it relates to NUMA architectures. It's a nice way of ensuring your changes don't break NUMA machines even if you don't have one. It's also a nice way to test different mempolicy and cpuset behavior. With regard to the fake-numa-for-cpusets document, it _is_ a very effective way of getting coarse memory isolation without using the per-page memory controller. You can use cpusets to isolate jobs to only be able to allocate from certain nodes; with a small enough node size, you can manage the memory resources available to applications on a fine granularity. That's not a popular use case, but it is useful for application development and benchmarking. I think it would be helpful to those particular users who are requesting it to enable it in Debian kernels since there is actually no cost associated with kernels that choose not to boot with numa=fake. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
