From: Eus <eus@member.fsf.org>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: proto_register() - Justification for requesting slab allocation
Date: Tue, 8 Apr 2008 05:36:12 -0700 (PDT) [thread overview]
Message-ID: <722741.62734.qm@web37601.mail.mud.yahoo.com> (raw)
Hi Ho!
Currently I am trying to implement a new type of socket in Linux kernel 2.6.21.5.
I am really curious about this function:
int proto_register(struct proto *prot, int alloc_slab)
I have investigated the source code and knew that, if alloc_slab is set to a
non-zero integer, kmem_cache_create() will create a memory slab for prot->slab.
At the end, when a socket needs to be created and sk_alloc() is invoked to create
the socket object, if prot->slab has been initialized with kmem_cache_create(),
sk_alloc() will simply create the socket object in the slab with
kmem_cache_alloc. Otherwise, sk_alloc() will create the socket object in the
ordinary way with kmalloc().
IMO, kmem_cache_alloc() should be less expensive than kmalloc() and, therefore,
it is a good thing to request slab allocation when invoking proto_register().
But, from all networking protocols that invoke proto_register(), 50% of them,
most of them are data link protocols, does not request slab allocation. The rest
that request slab allocation mainly is network layer protocols. That is why I
wonder whether or not there is an advantage of using kmalloc() over using
kmem_cache_alloc().
A friend of mine said that those that do not request slab allocation do so
because they are rarely used. But, I disagree because, although they are rarely
used, once they are used, they are used heavily, for example AF_PACKET, so that
it is a good idea to request slab allocation.
Therefore, what is the justification for requesting slab allocation or not?
Thank you very much.
Best regards,
Eus
____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.
http://tc.deals.yahoo.com/tc/blockbuster/text5.com
reply other threads:[~2008-04-08 12:43 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=722741.62734.qm@web37601.mail.mud.yahoo.com \
--to=eus@member.fsf.org \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox