Re: [PATCH 0/4] Fix ebizzy performance regression due to X86 TLBrange flush v2

[Ingo Molnar]

* Mel Gorman <mgorman@xxxxxxx> wrote:

> [...]
>
> At that point it'll be time to look at profiles and see where we are 
> actually spending time because the possibilities of finding things 
> to fix through bisection will be exhausted.

Yeah.

One (heavy handed but effective) trick that can be used in such a 
situation is to just revert everything that is causing problems, and 
continue reverting until we get back to a v3.4 baseline performance.

Once such a 'clean' tree (or queue of patches) is achived, that can be 
used as a measurement base and the individual features can be 
re-applied again, one by one, with measurement and analysis becoming a 
lot easier.

> > Also it appears the Ebizzy numbers ought to be stable enough now 
> > to make the range-TLB-flush measurements more precise?
> 
> Right now, the tlbflush microbenchmark figures look awful on the 
> 8-core machine when the tlbflush shift patch and the schedule domain 
> fix are both applied.

I think that furthr strengthens the case for the 'clean base' approach 
I outlined above - but it's your call obviously ...

Thanks again for going through all this. Tracking multi-commit 
performance regressions across 1.5 years worth of commits is generally 
very hard. Does your testing effort comes from enterprise Linux QA 
testing, or did you ran into this problem accidentally?

Thanks,

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