From: Eric Dumazet <dada1@cosmosbay.com>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [patch 6/13] signal/timer/event fds v7 - timerfd core ...
Date: Tue, 20 Mar 2007 01:36:11 +0100 [thread overview]
Message-ID: <45FF2C7B.6080107@cosmosbay.com> (raw)
In-Reply-To: <send-serie.davidel@xmailserver.org.15249.1174348074.6>
Davide Libenzi a écrit :
> +struct timerfd_ctx {
> + struct hrtimer tmr;
> + ktime_t tintv;
> + spinlock_t lock;
> + wait_queue_head_t wqh;
> + unsigned long ticks;
> +};
> +static struct kmem_cache *timerfd_ctx_cachep;
> + timerfd_ctx_cachep = kmem_cache_create("timerfd_ctx_cache",
> + sizeof(struct timerfd_ctx),
> + 0, SLAB_PANIC, NULL, NULL);
Do we really expect thousands of active timerfd_ctx ?
If not, using kmalloc()/kfree() would be fine, because sizeof(struct
timerfd_ctx) is so small.
on SMP / NUMA platforms, each new kmem_cache is rather expensive. (memory
allocated at kmem_cache_create(), but also memory used when cache is not
empty, with slabs in freelist for each cpu/node)
Using a general cache might be cheaper : No memory overhead for yet another
kmem_cache.
I know individual caches are good to spot memory leaks, but in timerfd case,
you dont have mem leaks, do you ? :)
next prev parent reply other threads:[~2007-03-20 0:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-19 23:47 [patch 6/13] signal/timer/event fds v7 - timerfd core Davide Libenzi
2007-03-20 0:36 ` Eric Dumazet [this message]
2007-03-20 1:36 ` Davide Libenzi
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=45FF2C7B.6080107@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=akpm@linux-foundation.org \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.