(replying to my own reply, fixing the lttng-dev mailing list address) ----- Original Message ----- > From: "Mathieu Desnoyers" <[email protected]> > To: "Stephen Hemminger" <[email protected]> > Cc: "Paul E. McKenney" <[email protected]>, [email protected] > Sent: Tuesday, October 22, 2013 6:14:31 AM > Subject: Re: rculfhash alternative allocator? > > ----- Original Message ----- > > From: "Stephen Hemminger" <[email protected]> > > To: "Mathieu Desnoyers" <[email protected]>, "Paul E. > > McKenney" <[email protected]> > > Cc: [email protected] > > 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 _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
