* Mel Gorman <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
