I think there are two fallouts form this discussion. First, there is the question of the precise semantics of the existing timing APIs as they relate to processor locality. Applications such as profiling tests, to the extent that they APIs that have processor-local semantics, must ensure that the thread(s) using these APIs are pinned for the duration of the measurement.
The other point is the one that Petri brought up about having other APIs that provide timing information based on wall time or other metrics that are not processor-local. While these may not have the same performance characteristics, they would be independent of thread migration considerations. Of course all this depends on exactly what one is trying to measure. Since thread migration is not free, allowing such activity may or may not be relevant to what is being measured, so ODP probably wants to have both processor-local and systemwide timing APIs. We just need to be sure they are specified precisely so that applications know how to use them properly. On Wed, May 4, 2016 at 10:23 AM, Mike Holmes <[email protected]> wrote: > It sounded like the arch call was leaning towards documenting that on > odp-linux the application must ensure that odp_threads are pinned to cores > when launched. > This is a restriction that some platforms may not need to make, vs the > idea that a piece of ODP code can use these APIs to ensure the behavior it > needs without knowledge or reliance on the wider system. > > On 4 May 2016 at 01:45, Yi He <[email protected]> wrote: > >> Establish a performance profiling environment guarantees meaningful >> and consistency of consecutive invocations of the odp_cpu_xxx() APIs. >> While after profiling was done restore the execution environment to >> its multi-core optimized state. >> >> Signed-off-by: Yi He <[email protected]> >> --- >> include/odp/api/spec/cpu.h | 31 +++++++++++++++++++++++++++++++ >> 1 file changed, 31 insertions(+) >> >> diff --git a/include/odp/api/spec/cpu.h b/include/odp/api/spec/cpu.h >> index 2789511..0bc9327 100644 >> --- a/include/odp/api/spec/cpu.h >> +++ b/include/odp/api/spec/cpu.h >> @@ -27,6 +27,21 @@ extern "C" { >> >> >> /** >> + * @typedef odp_profiler_t >> + * ODP performance profiler handle >> + */ >> + >> +/** >> + * Setup a performance profiling environment >> + * >> + * A performance profiling environment guarantees meaningful and >> consistency of >> + * consecutive invocations of the odp_cpu_xxx() APIs. >> + * >> + * @return performance profiler handle >> + */ >> +odp_profiler_t odp_profiler_start(void); >> + >> +/** >> * CPU identifier >> * >> * Determine CPU identifier on which the calling is running. CPU >> numbering is >> @@ -170,6 +185,22 @@ uint64_t odp_cpu_cycles_resolution(void); >> void odp_cpu_pause(void); >> >> /** >> + * Stop the performance profiling environment >> + * >> + * Stop performance profiling and restore the execution environment to >> its >> + * multi-core optimized state, won't preserve meaningful and consistency >> of >> + * consecutive invocations of the odp_cpu_xxx() APIs anymore. >> + * >> + * @param profiler performance profiler handle >> + * >> + * @retval 0 on success >> + * @retval <0 on failure >> + * >> + * @see odp_profiler_start() >> + */ >> +int odp_profiler_stop(odp_profiler_t profiler); >> + >> +/** >> * @} >> */ >> >> -- >> 1.9.1 >> >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> https://lists.linaro.org/mailman/listinfo/lng-odp >> > > > > -- > Mike Holmes > Technical Manager - Linaro Networking Group > Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs > "Work should be fun and collaborative, the rest follows" > > > > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp > >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
