On Thu, May 13, 2004 at 07:25:00AM -0000, bunty wrote:
>
> hi,
> >I don't know the exact extras it uses, but in allocation you want to
> >allocate the maximum memory you will need in this case so you won't
> >need to reallocate if more memory is needed.
> that mean actually kernel allocates more space than acually needed.
> Is that correct?
Yes, since it doesn't know at allocation time how much space will
actually be taken by the headers of each protocol, only the limits,
since the header sizes for most protocols is variable width.
In order to allocate exact sizes it would require two passes, first to
calculate the header sizes and then to actually allocate the space, and
that is more expensive then over allocation (since the kernel
over-allocates anyway - read on for that - and if you are careful it
won't matter)
Note that the kernel over-allocates anyway for sizes less then 128K due
to memory management issues, so considering the normal setting for the
MTU (1500) and since all the header overhead is less then 548 Byte you
are getting an allocation of 2048 Bytes anyway. You should be careful
in that respect with how much extra space you are allocating because if
you pass the 2048 mark you will get an allocation of 4092. Its a little
tight but possible.
If you want to see more, for skb look at alloc_skb in net/core/skbuff.c.
The skb itself is allocated of a pool of preallocated skbuffs (they are
sitting on the slabs in skbuff_head_cache, look in /proc/slabinfo, first
column is the used slabs, second is the allocated slabs and third is
slabsize, don't remember the rest of the columns).
The line allocating the skbuff (Head: i.e structure):
skb = kmem_cache_alloc(skbuff_head_cache, gfp_mask & ~__GFP_DMA);
The data is then allocated off the caches (not cached memory, under 128K
its the slabs IIRC) using kmalloc, which lives in mm/slab.c. Available
size are:
static cache_sizes_t cache_sizes[] = {
#if PAGE_SIZE == 4096
{ 32, NULL, NULL},
#endif
{ 64, NULL, NULL},
{ 128, NULL, NULL},
{ 256, NULL, NULL},
{ 512, NULL, NULL},
{ 1024, NULL, NULL},
{ 2048, NULL, NULL},
{ 4096, NULL, NULL},
{ 8192, NULL, NULL},
{ 16384, NULL, NULL},
{ 32768, NULL, NULL},
{ 65536, NULL, NULL},
{131072, NULL, NULL},
{ 0, NULL, NULL}
};
Allocating sizes smaller the 131072 gives you continuous memory IIRC,
more then that and you get non-continuous memory (the fall-back of 0 at
the end).
I'm not sure about the exact finer details since when I worked on this
it was with a system without virtual memory and about 3 years ago so
things were a little different but not too much)
> regards,
> parag.
>
>
> _[_h_t_t_p_:_/_/_a_d_s_._r_e_d_i_f_f_._c_o_m_/_R_e_a_l_M_e_d_i_a_/_a_d_s_/_a_d_s_t_r_e_a_m___n_x_._c_g_i_/_w_w_w_._r_e_d_i_f_f_m_a_i_l_._c_o_m_/
> _i_n_b_o_x_._h_t_m_@_B_o_t_t_o_m_]
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
