lkml.org 
[lkml]   [2008]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectproto_register() - Justification for requesting slab allocation
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


\
 
 \ /
  Last update: 2008-04-08 14:45    [W:0.030 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site