Re: [PATCH] sched/numa: Restore sched feature NUMA to its earlier avatar.

[Srikar Dronamraju <srikar@linux.vnet.ibm.com>]

> > In commit:8a9e62a "sched/numa: Prefer NUMA hotness over cache hotness"
> > sched feature NUMA was always set to true. However this sched feature was
> > suppose to be enabled on NUMA boxes only thro set_numabalancing_state().
> >
> > To get back to the above behaviour, bring back NUMA_FAVOUR_HIGHER feature.
> 
> Three typos and a non-standard commit ID reference.

Sorry .. Will fix it.
> 
> >  /*
> > + * NUMA_FAVOUR_HIGHER will favor moving tasks towards nodes where a
> > + * higher number of hinting faults are recorded during active load
> > + * balancing. It will resist moving tasks towards nodes where a lower
> > + * number of hinting faults have been recorded.
> >   */
> > -SCHED_FEAT(NUMA,	true)
> > +SCHED_FEAT(NUMA_FAVOUR_HIGHER, true)
> >  #endif
> > 
> 
> So the comment spells 'favor' American, the constant you introduce is British 
> spelling via 'FAVOUR'? Please use it consistently!
> 
> Also, this name is totally non-intuitive.
> 
> Make it something like NUMA_FAVOR_BUSY_NODES or so?

Okay will modify as suggested.

> 
> Also, I'm wondering how this can schedule in a stable fashion: if a non-busy node 
> is not favored, how can we end up there to start building up hinting faults?

The NUMA feature is suppose to be enabled automatically on numa system.
This feature is tied with starting the hinting faults.

However the other feature NUMA_FAVOUR_HIGHER / NUMA_FAVOR_BUSY_NODES
will only affect if we want to give a numa bias when we do the regular
load balance. It wouldnt affect numa hinting faults or the tasks swaps
that we do based on numa faults. So its impact is very limited.

Would you recommend removing the feature?

-- 
Thanks and Regards
Srikar Dronamraju