Messages in this thread | | | Date | Thu, 14 Nov 2013 09:39:30 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] Perf: Correct Assumptions about Sample Timestamps in Passes |
| |
* Joseph Schuchart <joseph.schuchart@tu-dresden.de> wrote:
> @@ -549,15 +552,24 @@ static int flush_sample_queue(struct perf_session *s, > return 0; > } > > +static inline void set_next_flush(struct perf_session *session) > +{ > + int i; > + u64 min_max_timestamp = session->ordered_samples.max_timestamps[0]; > + for (i = 1; i < MAX_NR_CPUS; i++) { > + if (min_max_timestamp > session->ordered_samples.max_timestamps[i]) > + min_max_timestamp = session->ordered_samples.max_timestamps[i]; > + } > + session->ordered_samples.next_flush = min_max_timestamp; > +}
> static int process_finished_round(struct perf_tool *tool, > union perf_event *event __maybe_unused, > struct perf_session *session) > { > - int ret = flush_sample_queue(session, tool); > - if (!ret) > - session->ordered_samples.next_flush = session->ordered_samples.max_timestamp; > - > + int ret; > + set_next_flush(session); > + ret = flush_sample_queue(session, tool);
Just a quick side note, while I realize that you are (rightfully!) concerned about correctness primarily, if that loop over MAX_NR_CPUS executes often enough then this might hurt performance:
perf.h:#define MAX_NR_CPUS 256
So it might be better to maintain a rolling min_max_timestamp in this place:
+ os->max_timestamps[sample->cpu] = timestamp;
?
If done that way then AFAICS we could even eliminate the ->max_timestamps[NR_CPUS] array.
Thanks,
Ingo
| |