We were doing parts of it in hists__collapse_resort and parts of it in
hists__output_resort, leading to a bogus total_period.
Fix it by doing just the filtering operation when collapsing because
there we know that the Zoom operations adds filters just  what is in
hists->entries, not to the new batch of entries being collapsed.
And move all the nr_entries + total_period recalculation to
hists__output_resort since we will traverse all entries anyway there.
Problem introduced when developing threaded addition of new batches
of hist_entries, i.e. post v3.1.
Reported-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-8xyh165h7hmwy0696hu25en6@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
 
        root = hists__get_rotate_entries_in(hists);
        next = rb_first(root);
-       hists->stats.total_period = 0;
 
        while (next) {
                n = rb_entry(next, struct hist_entry, rb_node_in);
                         * been set by, say, the hist_browser.
                         */
                        hists__apply_filters(hists, n);
-                       hists__inc_nr_entries(hists, n);
                }
        }
 }
        hists->entries = RB_ROOT;
 
        hists->nr_entries = 0;
+       hists->stats.total_period = 0;
        hists__reset_col_len(hists);
 
        while (next) {