lkml.org 
[lkml]   [2012]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2012-11-20 00:41    [W:0.143 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site