Messages in this thread | | | Date | Mon, 19 Mar 2012 22:34:17 +0100 | From | Ingo Molnar <> | Subject | Re: [RFC][PATCH 00/26] sched/numa |
| |
* Christoph Lameter <cl@linux.com> wrote:
> On Mon, 19 Mar 2012, Ingo Molnar wrote: > > > > I wonder how we can verify that the automatic migration > > > schemes are a real benefit to the application? We have a > > > history of developing a kernel that decreases in > > > performance as development proceeds. How can we make sure > > > that these schemes are actually beneficial overall for all > > > loads and do not cause regressions elsewhere? [...] > > > > The usual way? > > Which is merge after a couple of benchmarks and then deal with > the regressions for a couple of years? > > [...]
No, and I gave you my answer:
> Obviously any such scheme must be a win in general for it to be > default on. We don't have the numbers to justify that - and I'm > sceptical whether it will be possible, but I'm willing to be > surprised. > > I'm especially sceptical since most mainstream NUMA systems tend > to have a low NUMA factor. Thus the actual cost of being NUMA is > pretty low. > > That having said PeterZ's numbers showed some pretty good > improvement for the streams workload: > > before: 512.8M > after: 615.7M > > i.e. a +20% improvement on a not very heavily NUMA box. > > That kind of raw speedup of a CPU execution workload like > streams is definitely not something to ignore out of hand. *IF* > there is a good automatism that can activate it for the apps > that are very likely to benefit from it then we can possibly do > it. > > But a lot more measurements have to be done, and I'd be also > very interested in the areas that regress. > > Otherwise, if no robust automation is possible, it will have to > be opt-in, on a per app basis, with both programmatic and > sysadmin knobs available. (who will hopefully make use if it...) > > That's the best we can do I think.
Thanks,
Ingo
| |