All of lore.kernel.org
 help / color / mirror / Atom feed
* How to understand the macro __init?
@ 2012-08-14  2:14 王哲
  2012-08-14  4:04 ` Mulyadi Santosa
  0 siblings, 1 reply; 17+ messages in thread
From: 王哲 @ 2012-08-14  2:14 UTC (permalink / raw)
  To: kernelnewbies

 hi all

        in the kernel modules,we often use the macro __init.
if we only discuss the __init for functions.__init tells the
compiler to put  the function in a special section.and the
function are used once.So the code of this function should
be freed from the memory after the first call.

so i write a sample module:

#include <linux/module.h>
#include <linux/init.h>

void __init print_k(void)
{
    int k = 9;
    printk("<0>k = %d\n",k);
}

static int __init hello_init(void)
{
    printk("<0>hello kernel!\n");
    print_k();
    print_k();
    return 0;
}

static void __exit hello_exit(void)
{
    printk("<0>bye kernel!\n");
}

module_init(hello_init);
module_exit(hello_exit);
MODULE_LICENSE("GPL");

i use the __init for function print_k.
in my opinion  after the fisrt invoking the print_k in the hello_init.
the memory of print_k will be freed,and the second invoking will
not be executed.but the result of second invoking is executing .

why?

Thanks in advance!
wanny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120814/2d3f8fef/attachment.html 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-14  2:14 How to understand the macro __init? 王哲
@ 2012-08-14  4:04 ` Mulyadi Santosa
  2012-08-14 11:34   ` Ezequiel Garcia
  2012-08-16 11:53   ` Vijay Chauhan
  0 siblings, 2 replies; 17+ messages in thread
From: Mulyadi Santosa @ 2012-08-14  4:04 UTC (permalink / raw)
  To: kernelnewbies

Hi.. :)

On Tue, Aug 14, 2012 at 9:14 AM, ?? <wangzhe5004@gmail.com> wrote:
> i use the __init for function print_k.
> in my opinion  after the fisrt invoking the print_k in the hello_init.
> the memory of print_k will be freed,and the second invoking will
> not be executed.but the result of second invoking is executing .
>
> why?

because you're still in module_init.... :)

right after modul init stage is done, _init marked function is thrown away...

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-14  4:04 ` Mulyadi Santosa
@ 2012-08-14 11:34   ` Ezequiel Garcia
  2012-08-14 11:46     ` 王哲
  2012-08-16 11:53   ` Vijay Chauhan
  1 sibling, 1 reply; 17+ messages in thread
From: Ezequiel Garcia @ 2012-08-14 11:34 UTC (permalink / raw)
  To: kernelnewbies

Hey wanny,

On Tue, Aug 14, 2012 at 1:04 AM, Mulyadi Santosa
<mulyadi.santosa@gmail.com> wrote:
> Hi.. :)
>
> On Tue, Aug 14, 2012 at 9:14 AM, ?? <wangzhe5004@gmail.com> wrote:
>> i use the __init for function print_k.
>> in my opinion  after the fisrt invoking the print_k in the hello_init.
>> the memory of print_k will be freed,and the second invoking will
>> not be executed.but the result of second invoking is executing .
>>
>> why?
>
> because you're still in module_init.... :)
>
>

Yes, and the function is still in the stack!

On the other hand.. think what would happen if things would work
like you say.

We would have a *very* strange behavior,
and pretty counter-intuitive, don't you think so?

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-14 11:34   ` Ezequiel Garcia
@ 2012-08-14 11:46     ` 王哲
  2012-08-14 12:09       ` Ezequiel Garcia
  0 siblings, 1 reply; 17+ messages in thread
From: 王哲 @ 2012-08-14 11:46 UTC (permalink / raw)
  To: kernelnewbies

2012/8/14 Ezequiel Garcia <elezegarcia@gmail.com>

> Hey wanny,
>
> On Tue, Aug 14, 2012 at 1:04 AM, Mulyadi Santosa
> <mulyadi.santosa@gmail.com> wrote:
> > Hi.. :)
> >
> > On Tue, Aug 14, 2012 at 9:14 AM, ?? <wangzhe5004@gmail.com> wrote:
> >> i use the __init for function print_k.
> >> in my opinion  after the fisrt invoking the print_k in the hello_init.
> >> the memory of print_k will be freed,and the second invoking will
> >> not be executed.but the result of second invoking is executing .
> >>
> >> why?
> >
> > because you're still in module_init.... :)
> >
> >
>
> Yes, and the function is still in the stack!
>
> On the other hand.. think what would happen if things would work
> like you say.
>
> We would have a *very* strange behavior,
> and pretty counter-intuitive, don't you think so?
>

   Thank you very much  for reply.
   as you say,and function is still in the stack,don't be freed
   in the memory,what is __init had done? who can give a sample example
  to explain the difference existing __init or not?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120814/4407cb10/attachment.html 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-14 11:46     ` 王哲
@ 2012-08-14 12:09       ` Ezequiel Garcia
  2012-08-16  9:45         ` stl
  0 siblings, 1 reply; 17+ messages in thread
From: Ezequiel Garcia @ 2012-08-14 12:09 UTC (permalink / raw)
  To: kernelnewbies

On Tue, Aug 14, 2012 at 8:46 AM, ?? <wangzhe5004@gmail.com> wrote:
>
>
> 2012/8/14 Ezequiel Garcia <elezegarcia@gmail.com>
>>
>> Hey wanny,
>>
>> On Tue, Aug 14, 2012 at 1:04 AM, Mulyadi Santosa
>> <mulyadi.santosa@gmail.com> wrote:
>> > Hi.. :)
>> >
>> > On Tue, Aug 14, 2012 at 9:14 AM, ?? <wangzhe5004@gmail.com> wrote:
>> >> i use the __init for function print_k.
>> >> in my opinion  after the fisrt invoking the print_k in the hello_init.
>> >> the memory of print_k will be freed,and the second invoking will
>> >> not be executed.but the result of second invoking is executing .
>> >>
>> >> why?
>> >
>> > because you're still in module_init.... :)
>> >
>> >
>>
>> Yes, and the function is still in the stack!
>>
>> On the other hand.. think what would happen if things would work
>> like you say.
>>
>> We would have a *very* strange behavior,
>> and pretty counter-intuitive, don't you think so?
>
>
>    Thank you very much  for reply.
>    as you say,and function is still in the stack,don't be freed
>    in the memory,what is __init had done? who can give a sample example
>   to explain the difference existing __init or not?

This is documented in Documentation/DocBook/....

    After boot, the kernel frees up a special section; functions
    marked with __init and data structures marked with
    __initdata are dropped after boot is complete: similarly
    modules discard this memory after initialization.  __exit
    is used to declare a function which is only required on exit: the
    function will be dropped if this file is not compiled as a module.
    See the header file for use. Note that it makes no sense for a function
    marked with __init to be exported to modules with
    EXPORT_SYMBOL() - this will break.

I'll try to put it in plain english, I'm sure someone will correct
me if I mess up:

When the kernel starts (machine boots), kernel code and data are
loaded onto RAM*.
But some code and some data is only needed for initialization, and
there's no point
on keeping them around after this stage is done. So it gets "dropped",
i.e. it's removed from RAM. But of course, this is done when the kernel
knows it won't need it anymore.

Since a module is like a little piece of kernel that gets loaded dynamically,
I guess you can think it work more or less the same way.

Hope it's clear now (and hope it's correct :-)

Ezequiel.

* This is pretty much like any executable binary, except kernel won't page out
so it has to be completely loaded in RAM.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-14 12:09       ` Ezequiel Garcia
@ 2012-08-16  9:45         ` stl
  2012-08-16  9:50           ` stl
  0 siblings, 1 reply; 17+ messages in thread
From: stl @ 2012-08-16  9:45 UTC (permalink / raw)
  To: kernelnewbies

To be more precise, all the content of the .init section will be freed at
the end of the boot. (see vmlinux.lds.S)
This is done by the function "free_initmem()" which is an architecture
specific function defined in linux-*/arch/<arch>/mm/init.c.

This function frees the memory between the symbols __init_begin and
__init_end (which need to be page-aligned).

During compilation, all symbols defined with __init macro are put in the
.init section.
As explained before, these a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120816/36fa506b/attachment.html 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-16  9:45         ` stl
@ 2012-08-16  9:50           ` stl
  0 siblings, 0 replies; 17+ messages in thread
From: stl @ 2012-08-16  9:50 UTC (permalink / raw)
  To: kernelnewbies

sorry for the wrong manipulation

(resume of the previous mail)
As explained before, the symbols and functions defined with __init are only
used during boot initialization.
Thez will never be used again.
So The entire .init section is freed, and this freed memory will become
available memory pages for the kernel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120816/664fcabc/attachment.html 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-14  4:04 ` Mulyadi Santosa
  2012-08-14 11:34   ` Ezequiel Garcia
@ 2012-08-16 11:53   ` Vijay Chauhan
  2012-08-16 14:31     ` Amarnath Revanna
  1 sibling, 1 reply; 17+ messages in thread
From: Vijay Chauhan @ 2012-08-16 11:53 UTC (permalink / raw)
  To: kernelnewbies

Hi,

On Tue, Aug 14, 2012 at 9:34 AM, Mulyadi Santosa
<mulyadi.santosa@gmail.com> wrote:
> Hi.. :)
>
> On Tue, Aug 14, 2012 at 9:14 AM, ?? <wangzhe5004@gmail.com> wrote:
>> i use the __init for function print_k.
>> in my opinion  after the fisrt invoking the print_k in the hello_init.
>> the memory of print_k will be freed,and the second invoking will
>> not be executed.but the result of second invoking is executing .
>>
>> why?
>
> because you're still in module_init.... :)
>
> right after modul init stage is done, _init marked function is thrown away...


Even if we call  print_k() function inside hello_exit, it still works.
At that point __init hello_init execution is over. How its still
working?


Regards,
Vijay

>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-16 11:53   ` Vijay Chauhan
@ 2012-08-16 14:31     ` Amarnath Revanna
  2012-08-16 15:13       ` 王哲
  0 siblings, 1 reply; 17+ messages in thread
From: Amarnath Revanna @ 2012-08-16 14:31 UTC (permalink / raw)
  To: kernelnewbies

Hi Vijay,

Is this a loadable kernel module or a built-in module?
If it is a loadable module, everything still remains in the memory without
being freed.

Functions and data defined with __init gets freed after their execution
only if these are part of built-in kernel modules.

In your case, if the module is a loadable one, you can still access the
print_k() from hello_exit() as its still residing in memory.

Regards,
-Amar

On Thu, Aug 16, 2012 at 5:23 PM, Vijay Chauhan <kernel.vijay@gmail.com>wrote:

> Hi,
>
> On Tue, Aug 14, 2012 at 9:34 AM, Mulyadi Santosa
> <mulyadi.santosa@gmail.com> wrote:
> > Hi.. :)
> >
> > On Tue, Aug 14, 2012 at 9:14 AM, ?? <wangzhe5004@gmail.com> wrote:
> >> i use the __init for function print_k.
> >> in my opinion  after the fisrt invoking the print_k in the hello_init.
> >> the memory of print_k will be freed,and the second invoking will
> >> not be executed.but the result of second invoking is executing .
> >>
> >> why?
> >
> > because you're still in module_init.... :)
> >
> > right after modul init stage is done, _init marked function is thrown
> away...
>
>
> Even if we call  print_k() function inside hello_exit, it still works.
> At that point __init hello_init execution is over. How its still
> working?
>
>
> Regards,
> Vijay
>
> >
> > --
> > regards,
> >
> > Mulyadi Santosa
> > Freelance Linux trainer and consultant
> >
> > blog: the-hydra.blogspot.com
> > training: mulyaditraining.blogspot.com
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120816/55548287/attachment.html 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-16 14:31     ` Amarnath Revanna
@ 2012-08-16 15:13       ` 王哲
  2012-08-16 16:08         ` Amarnath Revanna
  0 siblings, 1 reply; 17+ messages in thread
From: 王哲 @ 2012-08-16 15:13 UTC (permalink / raw)
  To: kernelnewbies

2012/8/16 Amarnath Revanna <amarnath.revanna@gmail.com>

> Hi Vijay,
>
> Is this a loadable kernel module or a built-in module?
> If it is a loadable module, everything still remains in the memory without
> being freed.
>
> Functions and data defined with __init gets freed after their execution
> only if these are part of built-in kernel modules.
>
> In your case, if the module is a loadable one, you can still access the
> print_k() from hello_exit() as its still residing in memory.
>
> Regards,
> -Amar
>

   Hi Amar

       Thank you  very much  for reply. I often write loadable modules,but
know little about
built-in modules,can you tell something about built-in modules? or,how i
can take a built-in
module into the kernel?


> On Thu, Aug 16, 2012 at 5:23 PM, Vijay Chauhan <kernel.vijay@gmail.com>wrote:
>
>> Hi,
>>
>> On Tue, Aug 14, 2012 at 9:34 AM, Mulyadi Santosa
>> <mulyadi.santosa@gmail.com> wrote:
>> > Hi.. :)
>> >
>> > On Tue, Aug 14, 2012 at 9:14 AM, ?? <wangzhe5004@gmail.com> wrote:
>> >> i use the __init for function print_k.
>> >> in my opinion  after the fisrt invoking the print_k in the hello_init.
>> >> the memory of print_k will be freed,and the second invoking will
>> >> not be executed.but the result of second invoking is executing .
>> >>
>> >> why?
>> >
>> > because you're still in module_init.... :)
>> >
>> > right after modul init stage is done, _init marked function is thrown
>> away...
>>
>>
>> Even if we call  print_k() function inside hello_exit, it still works.
>> At that point __init hello_init execution is over. How its still
>> working?
>>
>>
>> Regards,
>> Vijay
>>
>> >
>> > --
>> > regards,
>> >
>> > Mulyadi Santosa
>> > Freelance Linux trainer and consultant
>> >
>> > blog: the-hydra.blogspot.com
>> > training: mulyaditraining.blogspot.com
>> >
>> > _______________________________________________
>> > Kernelnewbies mailing list
>> > Kernelnewbies at kernelnewbies.org
>> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120816/a7af0625/attachment.html 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-16 15:13       ` 王哲
@ 2012-08-16 16:08         ` Amarnath Revanna
  2012-08-16 17:23           ` Ezequiel Garcia
  0 siblings, 1 reply; 17+ messages in thread
From: Amarnath Revanna @ 2012-08-16 16:08 UTC (permalink / raw)
  To: kernelnewbies

Hi Wanny,

On Thu, Aug 16, 2012 at 8:43 PM, ?? <wangzhe5004@gmail.com> wrote:

>
>
> 2012/8/16 Amarnath Revanna <amarnath.revanna@gmail.com>
>
>> Hi Vijay,
>>
>> Is this a loadable kernel module or a built-in module?
>> If it is a loadable module, everything still remains in the memory
>> without being freed.
>>
>> Functions and data defined with __init gets freed after their execution
>> only if these are part of built-in kernel modules.
>>
>> In your case, if the module is a loadable one, you can still access the
>> print_k() from hello_exit() as its still residing in memory.
>>
>> Regards,
>> -Amar
>>
>
>    Hi Amar
>
>        Thank you  very much  for reply. I often write loadable modules,but
> know little about
> built-in modules,can you tell something about built-in modules? or,how i
> can take a built-in
> module into the kernel?
>


When I say built-in module, I meant to say the driver module is going to be
part of kernel itself, i.e. the module is compiled as part of kernel and
not explicitly loaded later.
The __init macros are applicable only for these modules that are
initialized as part of the kernel boot process.

At the end of the boot process, the kernel identifies all these memory
areas that are part of the init section that were required only during
initialization phase, and will continue to free these memory region to
re-use.

If you have a linux machine, you can do a dmesg to see this memory freeing
message that looks something something like:
" [1.011596] Freeing unused kernel memory: 664k freed "

This is exactly the freeing of all __init data sections from different
drivers/modules that were part of the kernel image. The freeing was done at
the end of the boot process, after they had  been used.

On the other hand, any other kernel module that you load using insmod or
modprobe comes after this stage, wherein the kernel was already booted, and
hence, no memory area of __init will ever be freed.

Regards,
-Amar





>
>
>> On Thu, Aug 16, 2012 at 5:23 PM, Vijay Chauhan <kernel.vijay@gmail.com>wrote:
>>
>>> Hi,
>>>
>>> On Tue, Aug 14, 2012 at 9:34 AM, Mulyadi Santosa
>>> <mulyadi.santosa@gmail.com> wrote:
>>> > Hi.. :)
>>> >
>>> > On Tue, Aug 14, 2012 at 9:14 AM, ?? <wangzhe5004@gmail.com> wrote:
>>> >> i use the __init for function print_k.
>>> >> in my opinion  after the fisrt invoking the print_k in the hello_init.
>>> >> the memory of print_k will be freed,and the second invoking will
>>> >> not be executed.but the result of second invoking is executing .
>>> >>
>>> >> why?
>>> >
>>> > because you're still in module_init.... :)
>>> >
>>> > right after modul init stage is done, _init marked function is thrown
>>> away...
>>>
>>>
>>> Even if we call  print_k() function inside hello_exit, it still works.
>>> At that point __init hello_init execution is over. How its still
>>> working?
>>>
>>>
>>> Regards,
>>> Vijay
>>>
>>> >
>>> > --
>>> > regards,
>>> >
>>> > Mulyadi Santosa
>>> > Freelance Linux trainer and consultant
>>> >
>>> > blog: the-hydra.blogspot.com
>>> > training: mulyaditraining.blogspot.com
>>> >
>>> > _______________________________________________
>>> > Kernelnewbies mailing list
>>> > Kernelnewbies at kernelnewbies.org
>>> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120816/4f7fa34c/attachment.html 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-16 16:08         ` Amarnath Revanna
@ 2012-08-16 17:23           ` Ezequiel Garcia
  2012-08-16 18:27             ` Amarnath Revanna
  0 siblings, 1 reply; 17+ messages in thread
From: Ezequiel Garcia @ 2012-08-16 17:23 UTC (permalink / raw)
  To: kernelnewbies

Hi Amar,

On Thu, Aug 16, 2012 at 1:08 PM, Amarnath Revanna
<amarnath.revanna@gmail.com> wrote:

>
> On the other hand, any other kernel module that you load using insmod or
> modprobe comes after this stage, wherein the kernel was already booted, and
> hence, no memory area of __init will ever be freed.
>

Modules are loaded with vmalloc, right?

Could you explain why the kernel can't free those __init symbols
from memory also in this case?

Thanks,
Ezequiel.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-16 17:23           ` Ezequiel Garcia
@ 2012-08-16 18:27             ` Amarnath Revanna
  2012-08-16 18:39               ` Amarnath Revanna
  0 siblings, 1 reply; 17+ messages in thread
From: Amarnath Revanna @ 2012-08-16 18:27 UTC (permalink / raw)
  To: kernelnewbies

Hi Ezequiel,

On Thu, Aug 16, 2012 at 10:53 PM, Ezequiel Garcia <elezegarcia@gmail.com>wrote:

> Hi Amar,
>
> On Thu, Aug 16, 2012 at 1:08 PM, Amarnath Revanna
> <amarnath.revanna@gmail.com> wrote:
>
> >
> > On the other hand, any other kernel module that you load using insmod or
> > modprobe comes after this stage, wherein the kernel was already booted,
> and
> > hence, no memory area of __init will ever be freed.
> >
>
> Modules are loaded with vmalloc, right?
>
> Could you explain why the kernel can't free those __init symbols
> from memory also in this case?
>
> Thanks,
> Ezequiel.
>

When we look at the definition of __init & __initdata in
http://lxr.free-electrons.com/source/include/linux/init.h#L44,

 44 <http://lxr.free-electrons.com/source/include/linux/init.h#L44>
#define __init <http://lxr.free-electrons.com/ident?i=__init>
__section <http://lxr.free-electrons.com/ident?i=__section>(.init
<http://lxr.free-electrons.com/ident?i=init>.text
<http://lxr.free-electrons.com/ident?i=text>) __cold
<http://lxr.free-electrons.com/ident?i=__cold> notrace
<http://lxr.free-electrons.com/ident?i=notrace>
 45 <http://lxr.free-electrons.com/source/include/linux/init.h#L45>
#define __initdata <http://lxr.free-electrons.com/ident?i=__initdata>
    __section <http://lxr.free-electrons.com/ident?i=__section>(.init
<http://lxr.free-electrons.com/ident?i=init>.data
<http://lxr.free-electrons.com/ident?i=data>)
 46 <http://lxr.free-electrons.com/source/include/linux/init.h#L46>
#define __initconst
<http://lxr.free-electrons.com/ident?i=__initconst>     __section
<http://lxr.free-electrons.com/ident?i=__section>(.init
<http://lxr.free-electrons.com/ident?i=init>.rodata
<http://lxr.free-electrons.com/ident?i=rodata>)
 47 <http://lxr.free-electrons.com/source/include/linux/init.h#L47>
#define __exitdata <http://lxr.free-electrons.com/ident?i=__exitdata>
    __section <http://lxr.free-electrons.com/ident?i=__section>(.exit
<http://lxr.free-electrons.com/ident?i=exit>.data
<http://lxr.free-electrons.com/ident?i=data>)
 48 <http://lxr.free-electrons.com/source/include/linux/init.h#L48>
#define __exit_call
<http://lxr.free-electrons.com/ident?i=__exit_call>     __used
<http://lxr.free-electrons.com/ident?i=__used> __section
<http://lxr.free-electrons.com/ident?i=__section>(.exitcall.exit
<http://lxr.free-electrons.com/ident?i=exit>)

we can notice that the functions represented by __init and any data
represented by __initdata are going to be placed
in a separate section of the final kernel binary image
(zImage/uImage/vmlinux)  by the linker.

This section is going to be called the .init section.

The idea behind forming this separate .init section in the final kernel
image is to hold all those functions and data structures
that are going to be required only once during initialization, together.

By doing so, the kernel, once it boots up, would have already utilized all
these resources once during bootup sequence and
hence, can now be released from the memory. As a result, the kernel would
simply discard this entire ".init" section from the
RAM in one go, there by freeing the memory. The amount of memory being
freed by removing this section is thus printed in
the line:

" [1.011596] Freeing unused kernel memory: 664k freed "

Now, when we think about loadable modules, as you rightly said, are loaded
into the kernel memory by obtaining the memory
area from the heap using vmalloc. The interesting thing about this is
that, since
we are going to load only one module
within this vmalloc'd area, we can normally expect the size of __initdata
and __init function to be pretty small, in few bytes.
Now, it becomes too difficult for the kernel to manage (keep track of and
free) these smaller memory areas coming up from
every individual loaded module.

Another thing to add is that, in case of freeing up an entire .init section
from the RAM, we are recovering the entire .init
section size'd _contiguous_ physical memory area back to the kernel.
However, in case of Loaded Kernel Module (LKM) if we
try to free up the __init memory of an LKM that was allocated using
vmalloc, we may only be freeing up few bytes of memory
that was virtually contiguous. This may not be of much significance for the
kernel operation as compared to its overhead
involved with managing a process to keep track of and freeing up all these
__init memory in vmalloc area.

In short, its kind of a nice trade off done to leave this __init data
cleanup for LKM while keeping its significance for all built in
drivers/modules.

Regards,
-Amar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120816/f26f356b/attachment-0001.html 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-16 18:27             ` Amarnath Revanna
@ 2012-08-16 18:39               ` Amarnath Revanna
  2012-08-16 18:49                 ` Ezequiel Garcia
  2012-09-03  6:27                 ` Jim Cromie
  0 siblings, 2 replies; 17+ messages in thread
From: Amarnath Revanna @ 2012-08-16 18:39 UTC (permalink / raw)
  To: kernelnewbies

Just want to add a little more for better understanding:

When I spoke about .init section of the final kernel image, please note
that this section is going to
contain all the __init data (and functions) coming from _All_ the drivers
and modules that were included
as part of the kernel image. Hence, after initialization when we look at
the print:

" [1.011596] Freeing unused kernel memory: 664k freed "

we see 664k bytes being freed.

This is a significant amount of contiguous physical memory that we can see
being released by the kernel.

The same cannot be held true for a single loadable module which may be
releasing just a few, virtually
contiguous memory.

Regards,
-Amar


On Thu, Aug 16, 2012 at 11:57 PM, Amarnath Revanna <
amarnath.revanna@gmail.com> wrote:

> Hi Ezequiel,
>
> On Thu, Aug 16, 2012 at 10:53 PM, Ezequiel Garcia <elezegarcia@gmail.com>wrote:
>
>> Hi Amar,
>>
>> On Thu, Aug 16, 2012 at 1:08 PM, Amarnath Revanna
>> <amarnath.revanna@gmail.com> wrote:
>>
>> >
>> > On the other hand, any other kernel module that you load using insmod or
>> > modprobe comes after this stage, wherein the kernel was already booted,
>> and
>> > hence, no memory area of __init will ever be freed.
>> >
>>
>> Modules are loaded with vmalloc, right?
>>
>> Could you explain why the kernel can't free those __init symbols
>> from memory also in this case?
>>
>> Thanks,
>> Ezequiel.
>>
>
> When we look at the definition of __init & __initdata in
> http://lxr.free-electrons.com/source/include/linux/init.h#L44,
>
>  44 <http://lxr.free-electrons.com/source/include/linux/init.h#L44> #define __init <http://lxr.free-electrons.com/ident?i=__init>          __section <http://lxr.free-electrons.com/ident?i=__section>(.init <http://lxr.free-electrons.com/ident?i=init>.text <http://lxr.free-electrons.com/ident?i=text>) __cold <http://lxr.free-electrons.com/ident?i=__cold> notrace <http://lxr.free-electrons.com/ident?i=notrace>
>  45 <http://lxr.free-electrons.com/source/include/linux/init.h#L45> #define __initdata <http://lxr.free-electrons.com/ident?i=__initdata>      __section <http://lxr.free-electrons.com/ident?i=__section>(.init <http://lxr.free-electrons.com/ident?i=init>.data <http://lxr.free-electrons.com/ident?i=data>)
>  46 <http://lxr.free-electrons.com/source/include/linux/init.h#L46> #define __initconst <http://lxr.free-electrons.com/ident?i=__initconst>     __section <http://lxr.free-electrons.com/ident?i=__section>(.init <http://lxr.free-electrons.com/ident?i=init>.rodata <http://lxr.free-electrons.com/ident?i=rodata>)
>  47 <http://lxr.free-electrons.com/source/include/linux/init.h#L47> #define __exitdata <http://lxr.free-electrons.com/ident?i=__exitdata>      __section <http://lxr.free-electrons.com/ident?i=__section>(.exit <http://lxr.free-electrons.com/ident?i=exit>.data <http://lxr.free-electrons.com/ident?i=data>)
>  48 <http://lxr.free-electrons.com/source/include/linux/init.h#L48> #define __exit_call <http://lxr.free-electrons.com/ident?i=__exit_call>     __used <http://lxr.free-electrons.com/ident?i=__used> __section <http://lxr.free-electrons.com/ident?i=__section>(.exitcall.exit <http://lxr.free-electrons.com/ident?i=exit>)
>
> we can notice that the functions represented by __init and any data
> represented by __initdata are going to be placed
> in a separate section of the final kernel binary image
> (zImage/uImage/vmlinux)  by the linker.
>
> This section is going to be called the .init section.
>
> The idea behind forming this separate .init section in the final kernel
> image is to hold all those functions and data structures
> that are going to be required only once during initialization, together.
>
> By doing so, the kernel, once it boots up, would have already utilized all
> these resources once during bootup sequence and
> hence, can now be released from the memory. As a result, the kernel would
> simply discard this entire ".init" section from the
> RAM in one go, there by freeing the memory. The amount of memory being
> freed by removing this section is thus printed in
> the line:
>
> " [1.011596] Freeing unused kernel memory: 664k freed "
>
> Now, when we think about loadable modules, as you rightly said, are loaded
> into the kernel memory by obtaining the memory
> area from the heap using vmalloc. The interesting thing about this is
> that, since we are going to load only one module
> within this vmalloc'd area, we can normally expect the size of __initdata
> and __init function to be pretty small, in few bytes.
> Now, it becomes too difficult for the kernel to manage (keep track of and
> free) these smaller memory areas coming up from
> every individual loaded module.
>
> Another thing to add is that, in case of freeing up an entire .init
> section from the RAM, we are recovering the entire .init
> section size'd _contiguous_ physical memory area back to the kernel.
> However, in case of Loaded Kernel Module (LKM) if we
> try to free up the __init memory of an LKM that was allocated using
> vmalloc, we may only be freeing up few bytes of memory
> that was virtually contiguous. This may not be of much significance for
> the kernel operation as compared to its overhead
> involved with managing a process to keep track of and freeing up all
> these __init memory in vmalloc area.
>
> In short, its kind of a nice trade off done to leave this __init data
> cleanup for LKM while keeping its significance for all built in
> drivers/modules.
>
> Regards,
> -Amar
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120817/f741723e/attachment.html 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-16 18:39               ` Amarnath Revanna
@ 2012-08-16 18:49                 ` Ezequiel Garcia
  2012-08-16 19:41                   ` Amarnath Revanna
  2012-09-03  6:27                 ` Jim Cromie
  1 sibling, 1 reply; 17+ messages in thread
From: Ezequiel Garcia @ 2012-08-16 18:49 UTC (permalink / raw)
  To: kernelnewbies

Hey Amar,

On Thu, Aug 16, 2012 at 3:39 PM, Amarnath Revanna
<amarnath.revanna@gmail.com> wrote:
> Just want to add a little more for better understanding:
>
> When I spoke about .init section of the final kernel image, please note that
> this section is going to
> contain all the __init data (and functions) coming from _All_ the drivers
> and modules that were included
> as part of the kernel image. Hence, after initialization when we look at the
> print:
>
> " [1.011596] Freeing unused kernel memory: 664k freed "
>
> we see 664k bytes being freed.
>
> This is a significant amount of contiguous physical memory that we can see
> being released by the kernel.
>
> The same cannot be held true for a single loadable module which may be
> releasing just a few, virtually
> contiguous memory.
>

It's crystal clear ;-) Nice explanation. It's important to add
something to clearify a bit your
explanation (please correct me if I'm wrong):

When Amar is talking about "virtually contiguous" kernel memory he
implies that this
memory is physically *dis*contiguous, i.e. based on page-entries.
This is the kind of memory used for loadable modules,
for instance, modules that get loaded with modprobe.

On the other hand, built-in modules are compiled *inside*  the kernel
image (bzImage).
The memory used for this image is physically contiguous: it's a big
contiguous block
of memory pages. Contiguous memory is important for kernel, and therefore
is *very* important to spend some effort minimizing it.

Regards,
Ezequiel.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-16 18:49                 ` Ezequiel Garcia
@ 2012-08-16 19:41                   ` Amarnath Revanna
  0 siblings, 0 replies; 17+ messages in thread
From: Amarnath Revanna @ 2012-08-16 19:41 UTC (permalink / raw)
  To: kernelnewbies

On Fri, Aug 17, 2012 at 12:19 AM, Ezequiel Garcia <elezegarcia@gmail.com>wrote:

> Hey Amar,
>
> On Thu, Aug 16, 2012 at 3:39 PM, Amarnath Revanna
> <amarnath.revanna@gmail.com> wrote:
> > Just want to add a little more for better understanding:
> >
> > When I spoke about .init section of the final kernel image, please note
> that
> > this section is going to
> > contain all the __init data (and functions) coming from _All_ the drivers
> > and modules that were included
> > as part of the kernel image. Hence, after initialization when we look at
> the
> > print:
> >
> > " [1.011596] Freeing unused kernel memory: 664k freed "
> >
> > we see 664k bytes being freed.
> >
> > This is a significant amount of contiguous physical memory that we can
> see
> > being released by the kernel.
> >
> > The same cannot be held true for a single loadable module which may be
> > releasing just a few, virtually
> > contiguous memory.
> >
>
> It's crystal clear ;-) Nice explanation. It's important to add
> something to clearify a bit your
> explanation (please correct me if I'm wrong):
>
> When Amar is talking about "virtually contiguous" kernel memory he
> implies that this
> memory is physically *dis*contiguous, i.e. based on page-entries.
> This is the kind of memory used for loadable modules,
> for instance, modules that get loaded with modprobe.
>
> On the other hand, built-in modules are compiled *inside*  the kernel
> image (bzImage).
> The memory used for this image is physically contiguous: it's a big
> contiguous block
> of memory pages. Contiguous memory is important for kernel, and therefore
> is *very* important to spend some effort minimizing it.
>

Ezequiel,

Thanks for adding the clarification here :-)

Regards,
-Amar


>
> Regards,
> Ezequiel.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120817/c507aa5b/attachment-0001.html 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* How to understand the macro __init?
  2012-08-16 18:39               ` Amarnath Revanna
  2012-08-16 18:49                 ` Ezequiel Garcia
@ 2012-09-03  6:27                 ` Jim Cromie
  1 sibling, 0 replies; 17+ messages in thread
From: Jim Cromie @ 2012-09-03  6:27 UTC (permalink / raw)
  To: kernelnewbies

On Thu, Aug 16, 2012 at 12:39 PM, Amarnath Revanna
<amarnath.revanna@gmail.com> wrote:
> Just want to add a little more for better understanding:
>
> When I spoke about .init section of the final kernel image, please note that
> this section is going to
> contain all the __init data (and functions) coming from _All_ the drivers
> and modules that were included
> as part of the kernel image. Hence, after initialization when we look at the
> print:
>
> " [1.011596] Freeing unused kernel memory: 664k freed "
>
> we see 664k bytes being freed.
>
> This is a significant amount of contiguous physical memory that we can see
> being released by the kernel.
>
> The same cannot be held true for a single loadable module which may be
> releasing just a few, virtually
> contiguous memory.

FWIW, theres no reason that the loadable module's __init section must
be in the same allocation as the module code itself.

The lifetime is certainly different, so "pre-fragmenting" it could
leave fewer holes overall.
I dont know if this is actually done (this way), but it seems
reasonably likely, given that the per-module sections exist.

$ readelf -a /lib/modules/3.6.0-rc3-cha-dyndbg-00008-g6e433ac/kernel/drivers/usb/serial/pl2303.ko
| grep init
  [ 4] .init.text        PROGBITS        00000000 00197c 000019 00  AX  0   0  1
  [ 5] .rel.init.text    REL             00000000 02a58c 000020 08     44   4  4
00001754  0000b702 R_386_PC32        00000000   __init_waitqueue_head
Relocation section '.rel.init.text' at offset 0x2a58c contains 4 entries:
...


>
> Regards,
> -Amar
>
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2012-09-03  6:27 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-14  2:14 How to understand the macro __init? 王哲
2012-08-14  4:04 ` Mulyadi Santosa
2012-08-14 11:34   ` Ezequiel Garcia
2012-08-14 11:46     ` 王哲
2012-08-14 12:09       ` Ezequiel Garcia
2012-08-16  9:45         ` stl
2012-08-16  9:50           ` stl
2012-08-16 11:53   ` Vijay Chauhan
2012-08-16 14:31     ` Amarnath Revanna
2012-08-16 15:13       ` 王哲
2012-08-16 16:08         ` Amarnath Revanna
2012-08-16 17:23           ` Ezequiel Garcia
2012-08-16 18:27             ` Amarnath Revanna
2012-08-16 18:39               ` Amarnath Revanna
2012-08-16 18:49                 ` Ezequiel Garcia
2012-08-16 19:41                   ` Amarnath Revanna
2012-09-03  6:27                 ` Jim Cromie

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.