Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Subject: [ltt-dev] [PATCH 06/10 round10] add LFHT_MEMORY_CHUNK low level memory	management
Date: Wed, 23 Nov 2011 01:05:53 -0500	[thread overview]
Message-ID: <20111123060553.GC15964@Krystal> (raw)
In-Reply-To: <20111122102037.GG8332@Krystal>

Hi Lai,

* Mathieu Desnoyers (mathieu.desnoyers at efficios.com) wrote:
 [...]
> Hrm, this first level of indirection quickly becomes much larger than
> the order-based table. Have you measured gains with this approach ?
> 
> Can you detail the use-case for this approach ?
> 
> Have you measured the overhead of software fls() compared to the
> overhead of increases cache footprint of the larger table for the
> chunk-based approach ?

Hrm, I thought about this a little more last night, and my thoughts are
getting clearer in terms of memory management backends: I'm not against
the chunk-based memory allocation strategy per se, what I would like
though is to have these mm strategies added as plugins rather than as
#ifdef in the code of rculfhash.c. I see that we could introduce a
structure of callback pointers for e.g.

struct rculfhash_mm {
        struct cds_lfht *(*alloc)(unsigned long min_alloc_size,
                                unsigned long max_size);
        void (*alloc_bucket_table)(struct cds_lfht *ht, unsigned long order);
        void (*free_bucket_table)(struct cds_lfht *ht, unsigned long order);
};

We could then provide their implementation in separate files, e.g.

rculfhash-mm-order.c
rculfhash-mm-chunk.c
rculfhash-mm-mmap.c

A pointer to the mm strategy could be passed to cds_lfht_new upon
hash table creation.

We should probably try to unify the #ifdefs inside struct rcu_table to
put all the variants into a union. We should export the data structure
declarations needed by rculfhash-mm-* in a rculfhash-internal.h header,
placed along with the c files.

Now there is just bucket_at() that I would really like to keep inline.
Thoughts about how to do this efficiently and in a manageable way are
welcome. But I guess we should benchmark the performance difference
between inline and non-inline bucket_at(). It might end up that it's not
really worthwhile to try keeping it inline. Benchmarks would tell...

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com




  reply	other threads:[~2011-11-23  6:05 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-16  6:48 [ltt-dev] [PATCH 00/10 round10] rculfhash memory managements Lai Jiangshan
2011-11-16  6:48 ` [ltt-dev] [PATCH 01/10 round10] introduce bucket_at() and improve readability Lai Jiangshan
2011-11-22  9:58   ` Mathieu Desnoyers
2011-11-23  6:33     ` Lai Jiangshan
2011-11-23  6:50       ` Mathieu Desnoyers
2011-11-16  6:48 ` [ltt-dev] [PATCH 02/10 round10] proper wrapper for bucket table alloc and free Lai Jiangshan
2011-11-22 10:01   ` Mathieu Desnoyers
2011-11-23  6:36     ` Lai Jiangshan
2011-11-23  6:49       ` Mathieu Desnoyers
2011-11-16  6:48 ` [ltt-dev] [PATCH 03/10 round10] ht->t.size is no required larger than ht->min_table_size now Lai Jiangshan
2011-11-22 10:06   ` Mathieu Desnoyers
2011-11-23  7:05     ` Lai Jiangshan
2011-11-23  7:17       ` Mathieu Desnoyers
2011-11-16  6:48 ` [ltt-dev] [PATCH 04/10 round10] remove struct rcu_level Lai Jiangshan
2011-11-22 10:08   ` Mathieu Desnoyers
2011-11-16  6:48 ` [ltt-dev] [PATCH 05/10 round10] add max_size arguemnt Lai Jiangshan
2011-11-22 10:11   ` Mathieu Desnoyers
2011-11-23  7:13     ` Lai Jiangshan
2011-11-23  7:15       ` Mathieu Desnoyers
2011-11-16  6:48 ` [ltt-dev] [PATCH 06/10 round10] add LFHT_MEMORY_CHUNK low level memory management Lai Jiangshan
2011-11-22 10:20   ` Mathieu Desnoyers
2011-11-23  6:05     ` Mathieu Desnoyers [this message]
2011-11-23  8:11     ` Lai Jiangshan
2011-11-23  9:21       ` Mathieu Desnoyers
2011-11-16  6:48 ` [ltt-dev] [PATCH 07/10 round10] add LFHT_MEMORY_RESERVED " Lai Jiangshan
2011-11-17  2:15   ` Lai Jiangshan
2011-11-22 10:25   ` Mathieu Desnoyers
2011-11-16  6:48 ` [ltt-dev] [PATCH 08/10 round10] comments for " Lai Jiangshan
2011-11-16  6:48 ` [ltt-dev] [PATCH 09/10 round10] fix comments of cds_lfht_new() Lai Jiangshan
2011-11-23  5:46   ` Mathieu Desnoyers
2011-11-16  6:48 ` [ltt-dev] [PATCH 10/10 round10] add my name Lai Jiangshan
2011-11-23  5:48   ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111123060553.GC15964@Krystal \
    --to=mathieu.desnoyers@efficios.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox