hi,
I am very much thankful to you for your kind co operation on understanding memory allocation.
regards,
parag.
On Thu, 13 May 2004 Micha Feigin wrote :
>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/
>
