> 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.
I can understand your performance concerns. However, I am not sure how we can determine the minimal max_timestamp of all cpus without storing the information on a per-cpu basis first. Accumulating it on the fly would only lead to a global max_timestamp. If we had any information about the number of CPUs, we could limit the number of iterations in set_next_flush() to a minimum, though. However, that would require keeping track of the maximum cpu id while reading the samples. Or is there an easy way to determine the actual number cpus in the trace? Thanks Joseph > > Thanks, > > Ingo > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
