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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150708160627.GC26095@linux.vnet.ibm.com>
Date:	Wed, 8 Jul 2015 21:36:27 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, Rik van Riel <riel@...hat.com>,
	Mel Gorman <mgorman@...e.de>
Subject: Re: [PATCH] sched/numa: Restore sched feature NUMA to its earlier
 avatar.

> > 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/