* 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>