Re: [mm] f7b5d647946: -3.0% dbench.throughput-MB/sec

[Fengguang Wu]

On Tue, Aug 19, 2014 at 03:34:28PM +0100, Mel Gorman wrote:
> On Tue, Aug 19, 2014 at 12:41:34PM +0800, Fengguang Wu wrote:
> > Hi Mel,
> > 
> > We noticed a minor dbench throughput regression on commit
> > f7b5d647946aae1647bf5cd26c16b3a793c1ac49 ("mm: page_alloc: abort fair
> > zone allocation policy when remotes nodes are encountered").
> > 
> > testcase: ivb44/dbench/100%
> > 
> > bb0b6dffa2ccfbd  f7b5d647946aae1647bf5cd26
> > ---------------  -------------------------
> >      25692 Â 0%      -3.0%      24913 Â 0%  dbench.throughput-MB/sec
> >    6974259 Â 6%     -12.1%    6127616 Â 0%  meminfo.DirectMap2M
> >      18.43 Â 0%      -4.6%      17.59 Â 0%  turbostat.RAM_W
> >       9302 Â 0%      -3.6%       8965 Â 1%  time.user_time
> >    1425791 Â 1%      -2.0%    1396598 Â 0%  time.involuntary_context_switches
> > 
> > Disclaimer:
> > Results have been estimated based on internal Intel analysis and are provided
> > for informational purposes only. Any difference in system hardware or software
> > design or configuration may affect actual performance.
> > 
> 
> DirectMap2M changing is a major surprise and doesn't make sense for this
> machine.

The ivb44's hardware configuration is

        model: Ivytown Ivy Bridge-EP
        nr_cpu: 48
        memory: 64G

And note that this is an in-memory dbench run, which is why
dbench.throughput-MB/sec is so high.

> Did the amount of memory in the machine change between two tests?

Nope. They are back-to-back test runs, so the environment pretty much
remains the same.

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