On 26 January 2016 at 14:59, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> Reviewed-by: Petri Savolainen <petri.savolai...@nokia.com>
>
>
> > -----Original Message-----
> > From: EXT Zoltan Kiss [mailto:zoltan.k...@linaro.org]
> > Sent: Friday, January 22, 2016 8:24 PM
> > To: lng-odp@lists.linaro.org
> > Cc: ola.liljed...@arm.com; Savolainen, Petri (Nokia - FI/Espoo)
> > Subject: [API-NEXT PATCH 1/2] api: pool: allow per-thread caching
> >
> > This addition explicitly loses the requirement that a single thread
> should
> > be able to allocate the whole pool even if nothing used it before.
> > Therefore per-thread caches are allowed to retain some elements locally.
>
But is this a good change? How does it change the semantics of the ODP
memory management?
Threads can have local caches of buffers but if the local cache is
exhausted, a thread could steal buffers from other threads. This would mean
that the cache management has to be thread-safe (e.g. using atomic
instructions). There would still be a benefit of local buffer caches since
this would provide more cache locality for a thread/CPU. The cache metadata
would also be local to the cache (unless just accessed by some other CPU).

What's the overhead on e.g. x86 to use CAS to manage the local cache?


> >
> > Signed-off-by: Zoltan Kiss <zoltan.k...@linaro.org>
> > ---
> >  include/odp/api/pool.h | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/include/odp/api/pool.h b/include/odp/api/pool.h
> > index 2e79a55..deab963 100644
> > --- a/include/odp/api/pool.h
> > +++ b/include/odp/api/pool.h
> > @@ -43,6 +43,9 @@ extern "C" {
> >  /**
> >   * Pool parameters
> >   * Used to communicate pool creation options.
> > + * @note A single thread may not be able to allocate all 'num' elements
> > + * from the pool at any particular time, as other threads or hardware
> > + * blocks are allowed to keep some for caching purposes.
> >   */
> >  typedef struct odp_pool_param_t {
> >       /** Pool type */
> > --
> > 1.9.1
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to