Messages in this thread | | | Date | Mon, 19 Nov 2012 23:00:35 +0000 | From | Mel Gorman <> | Subject | Re: [PATCH 00/27] Latest numa/core release, v16 |
| |
On Mon, Nov 19, 2012 at 11:36:04PM +0100, Ingo Molnar wrote: > > * Mel Gorman <mgorman@suse.de> wrote: > > > Ok. > > > > In response to one of your later questions, I found that I had > > in fact disabled THP without properly reporting it. [...] > > Hugepages is a must for most forms of NUMA/HPC.
Requiring huge pages to avoid a regression is a mistake.
> This alone > questions the relevance of most of your prior numa/core testing > results. I now have to strongly dispute your other conclusions > as well. >
I'll freely admit that disabling THP for specjbb was a mistake and I should have caught why at the start. However, the autonumabench figures reported for the last release had THP enabled as had the kernel build benchmark figures.
> Just a look at 'perf top' output should have told you the story. >
I knew THP were not in use and said so in earlier reports. Take this for example -- https://lkml.org/lkml/2012/11/16/207 . For specjbb, note that the THP fault alloc figures are close to 0 and due to that I said "THP is not really a factor for this workload". What I failed to do was identify why THP was not in use.
> Yet time and time again you readily reported bad 'schednuma' > results for a slow 4K memory model that neither we nor other > NUMA testers I talked to actually used, without stopping to look > why that was so... >
Again, I apologise for the THP mistake. The fact remains that the other implementations did not suffer a performance slowdown due to the same mistake.
> [ I suspect that if such terabytes-of-data workloads are forced > through such a slow 4K pages model then there's a bug or > mis-tuning in our code that explains the level of additional > slowdown you saw - we'll fix that. > > But you should know that behavior under the slow 4K model > tells very little about the true scheduling and placement > quality of the patches... ] > > Please report proper THP-enabled numbers before continuing. >
Will do. Are THP-disabled benchmark results to be ignored?
-- Mel Gorman SUSE Labs
| |