On Tue, Nov 13, 2012 at 11:45:30AM +0100, Ingo Molnar wrote: > > * Mel Gorman <mgorman@xxxxxxx> wrote: > > > NOTE: This patch is based on "sched, numa, mm: Add fault driven > > placement and migration policy" but as it throws away > > all the policy to just leave a basic foundation I had to > > drop the signed-offs-by. > > So, much of that has been updated meanwhile - but the split > makes fundamental sense - we considered it before. > Yes, I saw the new series after I had written the changelog for V2. I decided to release a V2 anyway and plan to examine the revised patches and see what's in there. I hope to do that today, but it's more likely it will be tomorrow as some other issues have piled up on the TODO list. > One detail you did in this patch was the following rename: > > s/EMBEDDED_NUMA/NUMA_VARIABLE_LOCALITY > Yes. > > --- a/arch/sh/mm/Kconfig > > +++ b/arch/sh/mm/Kconfig > > @@ -111,6 +111,7 @@ config VSYSCALL > > config NUMA > > bool "Non Uniform Memory Access (NUMA) Support" > > depends on MMU && SYS_SUPPORTS_NUMA && EXPERIMENTAL > > + select NUMA_VARIABLE_LOCALITY > > default n > > help > > Some SH systems have many various memories scattered around > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > > > ..aaba45d 100644 > > --- a/init/Kconfig > > +++ b/init/Kconfig > > @@ -696,6 +696,20 @@ config LOG_BUF_SHIFT > > config HAVE_UNSTABLE_SCHED_CLOCK > > bool > > > > +# > > +# For architectures that (ab)use NUMA to represent different memory regions > > +# all cpu-local but of different latencies, such as SuperH. > > +# > > +config NUMA_VARIABLE_LOCALITY > > + bool > > The NUMA_VARIABLE_LOCALITY name slightly misses the real point > though that NUMA_EMBEDDED tried to stress: it's important to > realize that these are systems that (ab-)use our NUMA memory > zoning code to implement support for variable speed RAM modules > - so they can use the existing node binding ABIs. > > The cost of that is the losing of the regular NUMA node > structure. So by all means it's a convenient hack - but the name > must signal that. I'm not attached to the NUMA_EMBEDDED naming > overly strongly, but NUMA_VARIABLE_LOCALITY sounds more harmless > than it should. > > Perhaps ARCH_WANT_NUMA_VARIABLE_LOCALITY_OVERRIDE? A tad long > but we don't want it to be overused in any case. > I had two reasons for not using the NUMA_EMBEDDED name. 1. Embedded is too generic a term and could mean anything. There are x86 machines that are considered embedded who this option is meaningless for. It's be irritating to get mails about how they cannot enable the NUMA_EMBEDDED option for their embedded machine. 2. I encounter people periodically that plan to abuse NUMA for building things like ram-like regions backed by something else that are not arch-specific. In some cases, these are far from being for an embedded use-case. While I have heavily discouraged such NUMA abuse in the past I still kept it in mind for the naming. I'll go with the long name you suggest even though it's arch specific because I never want point 2 above to happen anyway. Maybe the name will poke the next person who plans to abuse NUMA in the eye hard enough to discourage them. -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>