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
Hi.. :)
On Tue, Aug 14, 2012 at 9:14 AM, ?? [off-list ref] 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
Hey wanny,
On Tue, Aug 14, 2012 at 1:04 AM, Mulyadi Santosa
[off-list ref] wrote:
Hi.. :)
On Tue, Aug 14, 2012 at 9:14 AM, ?? [off-list ref] wrote:
quoted
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?
Hey wanny,
On Tue, Aug 14, 2012 at 1:04 AM, Mulyadi Santosa
[off-list ref] wrote:
quoted
Hi.. :)
On Tue, Aug 14, 2012 at 9:14 AM, ?? [off-list ref] wrote:
quoted
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?
On Tue, Aug 14, 2012 at 8:46 AM, ?? [off-list ref] wrote:
2012/8/14 Ezequiel Garcia [off-list ref]
quoted
Hey wanny,
On Tue, Aug 14, 2012 at 1:04 AM, Mulyadi Santosa
[off-list ref] wrote:
quoted
Hi.. :)
On Tue, Aug 14, 2012 at 9:14 AM, ?? [off-list ref] wrote:
quoted
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.
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
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
Hi,
On Tue, Aug 14, 2012 at 9:34 AM, Mulyadi Santosa
[off-list ref] wrote:
Hi.. :)
On Tue, Aug 14, 2012 at 9:14 AM, ?? [off-list ref] wrote:
quoted
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
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 [off-list ref]wrote:
Hi,
On Tue, Aug 14, 2012 at 9:34 AM, Mulyadi Santosa
[off-list ref] wrote:
quoted
Hi.. :)
On Tue, Aug 14, 2012 at 9:14 AM, ?? [off-list ref] wrote:
quoted
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
quoted
--
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
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 [off-list ref]wrote:
quoted
Hi,
On Tue, Aug 14, 2012 at 9:34 AM, Mulyadi Santosa
[off-list ref] wrote:
quoted
Hi.. :)
On Tue, Aug 14, 2012 at 9:14 AM, ?? [off-list ref] wrote:
quoted
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
quoted
--
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
Hi Wanny,
On Thu, Aug 16, 2012 at 8:43 PM, ?? [off-list ref] wrote:
2012/8/16 Amarnath Revanna [off-list ref]
quoted
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
quoted
On Thu, Aug 16, 2012 at 5:23 PM, Vijay Chauhan [off-list ref]wrote:
quoted
Hi,
On Tue, Aug 14, 2012 at 9:34 AM, Mulyadi Santosa
[off-list ref] wrote:
quoted
Hi.. :)
On Tue, Aug 14, 2012 at 9:14 AM, ?? [off-list ref] wrote:
quoted
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
quoted
--
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
Hi Amar,
On Thu, Aug 16, 2012 at 1:08 PM, Amarnath Revanna
[off-list ref] 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.
Hi Ezequiel,
On Thu, Aug 16, 2012 at 10:53 PM, Ezequiel Garcia [off-list ref]wrote:
Hi Amar,
On Thu, Aug 16, 2012 at 1:08 PM, Amarnath Revanna
[off-list ref] wrote:
quoted
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
quoted
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.
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 [off-list ref]wrote:
quoted
Hi Amar,
On Thu, Aug 16, 2012 at 1:08 PM, Amarnath Revanna
[off-list ref] wrote:
quoted
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
quoted
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.
Hey Amar,
On Thu, Aug 16, 2012 at 3:39 PM, Amarnath Revanna
[off-list ref] 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.
On Fri, Aug 17, 2012 at 12:19 AM, Ezequiel Garcia [off-list ref]wrote:
Hey Amar,
On Thu, Aug 16, 2012 at 3:39 PM, Amarnath Revanna
[off-list ref] wrote:
quoted
Just want to add a little more for better understanding:
When I spoke about .init section of the final kernel image, please note
that
quoted
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
quoted
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
quoted
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
On Thu, Aug 16, 2012 at 12:39 PM, Amarnath Revanna
[off-list ref] 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:
...