Re: [PATCH] Perf: Correct Assumptions about Sample Timestamps inPasses

From: Joseph Schuchart
Date: Thu Nov 14 2013 - 03:59:26 EST


> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/