[lttng-dev] rculfhash alternative allocator?

[Mathieu Desnoyers]

(replying to my own reply, fixing the lttng-dev mailing list address)

----- Original Message -----
> From: "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>
> To: "Stephen Hemminger" <stephen at networkplumber.org>
> Cc: "Paul E. McKenney" <paulmck at linux.vnet.ibm.com>, lttng-dev at list.lttng.org
> Sent: Tuesday, October 22, 2013 6:14:31 AM
> Subject: Re: rculfhash alternative allocator?
> 
> ----- Original Message -----
> > From: "Stephen Hemminger" <stephen at networkplumber.org>
> > To: "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>, "Paul E.
> > McKenney" <paulmck at linux.vnet.ibm.com>
> > Cc: lttng-dev at list.lttng.org
> > Sent: Saturday, October 19, 2013 2:11:25 AM
> > Subject: rculfhash alternative allocator?
> 
> Hi Stephen,
> 
> > 
> > Would it be possible to expose the allocation handle for RCU lfhash?
> > In the Intel DPDK there is support for a version of malloc that allocates
> > out of the huge page pool. This is a fixed memory area that has lower
> > overhead because it is covered by a single TLB entry.
> > 
> > Internally rculfhash supports changing allocators but it doesn't have
> > an exposed API (for LGPL apps).
> 
> Well actually, rculfhash does expose an API allowing exactly this. If we look
> at URCU 0.8.0 _cds_lfht_new(), it takes a const struct cds_lfht_mm_type *mm
> parameter, which can be provided by the hash table user. Given it is not a
> typical use-case, this is hidden by the cds_lfht_new() wrapper, but the
> underscore-prefixed version can be used by advanced users.
> 
> The callbacks that need to be implemented by a memory management plugin are
> detailed in urcu/rculfhash.h too:
> 
> struct cds_lfht_mm_type {
>         struct cds_lfht *(*alloc_cds_lfht)(unsigned long
>         min_nr_alloc_buckets,
>                         unsigned long max_nr_buckets);
>         void (*alloc_bucket_table)(struct cds_lfht *ht, unsigned long order);
>         void (*free_bucket_table)(struct cds_lfht *ht, unsigned long order);
>         struct cds_lfht_node *(*bucket_at)(struct cds_lfht *ht,
>                         unsigned long index);
> };
> 
> So my recommendation would be to create a new memory management plugin
> derived from one already closely matching your constraints.
> 
> Thoughts ?
> 
> > 
> > 
> > Ps: would be good to add mailing list to README?
> > 
> 
> I wanted to wait until we create a mailing list specifically for URCU, but
> indeed, it might not hurt to point to the lttng-dev mailing list meanwhile.
> I've just added it to the README file.
> 
> Thanks!
> 
> Mathieu
> 
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com