Slow loading big kernel module in 2.6 on PPC platform

Slow loading big kernel module in 2.6 on PPC platform

[Wilson Li]

Hi,

I am trying to port several third party kernel modules from kernel
2.4 to 2.6 on a ppc (MPC824x) platform. For small size of modules, it
works perfectly in 2.6. But there's one huge kernel module which size
is about 2.7M bytes (size reported by lsmod after insmod), and it
takes about 90 seconds to load this module before init_module starts.
I did not notice there's such obvious delay in 2.4 kernel.

Initially I suspected there might be a problem of the insmod of
busybox I was using. I switched to module-init-tools-3.1 insmod. It
didn't help. I also tried other things like disabling CONFIG_KALLSYMS
and commenting out all the EXPORT_SYMBOLs in that module. Nothing
works so far. I've not been able to find any relevant thread about
slow loading of big kernel module on PPC platform.

Is this related to the new way of loading kernel module in 2.6 or
vmalloc since the kernel module also needs contiguous memory? I am
running 2.6.8 kernel on a ppc platform (MPC824x) with 24M bytes
memory visible to kernel. Two small kernel modules are loaded first
through shell command right after system boots up. And there are
about 10M bytes free memory left before loading this big chunk. The
memory seems big enough to me and memory is not that fragmented since
it just boots up. 

Any suggestions?

Thanks a lot,
Wilson Li






		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: Slow loading big kernel module in 2.6 on PPC platform

[linux-os (Dick Johnson)]

On Wed, 28 Sep 2005, Wilson Li wrote:

> Hi,
>
> I am trying to port several third party kernel modules from kernel
> 2.4 to 2.6 on a ppc (MPC824x) platform. For small size of modules, it
> works perfectly in 2.6. But there's one huge kernel module which size
> is about 2.7M bytes (size reported by lsmod after insmod), and it
> takes about 90 seconds to load this module before init_module starts.
> I did not notice there's such obvious delay in 2.4 kernel.
>

I don't think it's a problem with the size. Here is the
`lspci` output after I hacked a Rtc module to use 16 megabytes
of data space. It took about 1/4 second to load (`time insmod Rtc.ko`).

Module                  Size  Used by
Rtc                 16783748  0
floppy                 58964  0
loop                   18440  0
parport_pc             28740  1
lp                     14472  0
parport                37320  2 parport_pc,lp

[SNIPPED...]


> Initially I suspected there might be a problem of the insmod of
> busybox I was using. I switched to module-init-tools-3.1 insmod. It
> didn't help. I also tried other things like disabling CONFIG_KALLSYMS
> and commenting out all the EXPORT_SYMBOLs in that module. Nothing
> works so far. I've not been able to find any relevant thread about
> slow loading of big kernel module on PPC platform.
>

The PPC might be a bit slower, but not as slow as you are
seeing. I suspect that you have something that is 'waiting'
for initialization.

> Is this related to the new way of loading kernel module in 2.6 or
> vmalloc since the kernel module also needs contiguous memory? I am
> running 2.6.8 kernel on a ppc platform (MPC824x) with 24M bytes
> memory visible to kernel. Two small kernel modules are loaded first
> through shell command right after system boots up. And there are
> about 10M bytes free memory left before loading this big chunk. The
> memory seems big enough to me and memory is not that fragmented since
> it just boots up.
>
> Any suggestions?
>
> Thanks a lot,
> Wilson Li

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Slow loading big kernel module in 2.6 on PPC platform

[Wilson Li]

--- "linux-os (Dick Johnson)" <linux-os@analogic.com> wrote:

> 
> On Wed, 28 Sep 2005, Wilson Li wrote:
> 
> > Hi,
> >
> > I am trying to port several third party kernel modules from
> kernel
> > 2.4 to 2.6 on a ppc (MPC824x) platform. For small size of
> modules, it
> > works perfectly in 2.6. But there's one huge kernel module which
> size
> > is about 2.7M bytes (size reported by lsmod after insmod), and it
> > takes about 90 seconds to load this module before init_module
> starts.
> > I did not notice there's such obvious delay in 2.4 kernel.
> >
> 
> I don't think it's a problem with the size. Here is the
> `lspci` output after I hacked a Rtc module to use 16 megabytes
> of data space. It took about 1/4 second to load (`time insmod
> Rtc.ko`).
> 
> Module                  Size  Used by
> Rtc                 16783748  0
> floppy                 58964  0
> loop                   18440  0
> parport_pc             28740  1
> lp                     14472  0
> parport                37320  2 parport_pc,lp
> 
> [SNIPPED...]
> 
> 
> > Initially I suspected there might be a problem of the insmod of
> > busybox I was using. I switched to module-init-tools-3.1 insmod.
> It
> > didn't help. I also tried other things like disabling
> CONFIG_KALLSYMS
> > and commenting out all the EXPORT_SYMBOLs in that module. Nothing
> > works so far. I've not been able to find any relevant thread
> about
> > slow loading of big kernel module on PPC platform.
> >
> 
> The PPC might be a bit slower, but not as slow as you are
> seeing. I suspect that you have something that is 'waiting'
> for initialization.

For debugging, my module init function will print a message first
when it gets called. After insmod the module, the console hangs about
90 seconds for loading then my init function gets called and message
prints. I even commented out all the initialization code, it still
does not help. Anything else I am missing?

Thanks,
Wilson Li


	
		
______________________________________________________ 
Yahoo! for Good 
Donate to the Hurricane Katrina relief effort. 
http://store.yahoo.com/redcross-donate3/ 

Re: Slow loading big kernel module in 2.6 on PPC platform

[linux-os (Dick Johnson)]

On Wed, 28 Sep 2005, Wilson Li wrote:

>
>
> --- "linux-os (Dick Johnson)" <linux-os@analogic.com> wrote:
>
>>
>> On Wed, 28 Sep 2005, Wilson Li wrote:
>>
>>> Hi,
>>>
>>> I am trying to port several third party kernel modules from
>> kernel
>>> 2.4 to 2.6 on a ppc (MPC824x) platform. For small size of
>> modules, it
>>> works perfectly in 2.6. But there's one huge kernel module which
>> size
>>> is about 2.7M bytes (size reported by lsmod after insmod), and it
>>> takes about 90 seconds to load this module before init_module
>> starts.
>>> I did not notice there's such obvious delay in 2.4 kernel.
>>>
>>
>> I don't think it's a problem with the size. Here is the
>> `lspci` output after I hacked a Rtc module to use 16 megabytes
>> of data space. It took about 1/4 second to load (`time insmod
>> Rtc.ko`).
>>
>> Module                  Size  Used by
>> Rtc                 16783748  0
>> floppy                 58964  0
>> loop                   18440  0
>> parport_pc             28740  1
>> lp                     14472  0
>> parport                37320  2 parport_pc,lp
>>
>> [SNIPPED...]
>>
>>
>>> Initially I suspected there might be a problem of the insmod of
>>> busybox I was using. I switched to module-init-tools-3.1 insmod.
>> It
>>> didn't help. I also tried other things like disabling
>> CONFIG_KALLSYMS
>>> and commenting out all the EXPORT_SYMBOLs in that module. Nothing
>>> works so far. I've not been able to find any relevant thread
>> about
>>> slow loading of big kernel module on PPC platform.
>>>
>>
>> The PPC might be a bit slower, but not as slow as you are
>> seeing. I suspect that you have something that is 'waiting'
>> for initialization.
>
> For debugging, my module init function will print a message first
> when it gets called. After insmod the module, the console hangs about
> 90 seconds for loading then my init function gets called and message
> prints. I even commented out all the initialization code, it still
> does not help. Anything else I am missing?
>
> Thanks,
> Wilson Li

I have a module I am currently working on. It has some assembly
stuff linked with it, so it was easy to modify. In the assembly
I allocated 16 megabytes of static storage (using the .space keyword),
first in the .data section, then in .rodata, then in .text. The
.text section is where code exists. In no case did the module take
more than 1/4 second to load. In all cases the size shown by `lsmod`
reflected the enormous size of the module.

Now, that's static storage. If your code uses kmalloc() and
friends to allocate a lot of storage when it is being loaded,
then that's a different story. FYI, when you see a kernel message
on the screen, that's not necessarily when it was "printed". It
gets buffered, you know. If you want to time-check when various
sections get control, to find out what's eating the time, then
put the jiffie count into your kernel messages.

A simple macro using the __FUNCTION__ string and the jiffie
count can go a long way towards finding out what's happening.

For instance, I once had a problem with continuous interrupts
from a device, that couldn't be cleared, until the device was
initialized. That slowed the system to a stand-still until
I found that. The fix was easy, do some initialization before
attaching the interrupt, at least enough to quiet the board.
This board had an empty FPGA, whos bits need to be loaded
with a bit-banger to make it work. The pin connected to an
interrupt was just whatever-it-was-from-the-factory, before
the intelligence was loaded. That system took about a minute
for the first kernel message to be printed. Sometimes the
system was very quiet <forever> and needed to be kicked.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Slow loading big kernel module in 2.6 on PPC platform

[Wilson Li]

>--- "linux-os (Dick Johnson)" <linux-os@analogic.com> wrote:
> 
> On Wed, 28 Sep 2005, Wilson Li wrote:
> 
> I have a module I am currently working on. It has some assembly
> stuff linked with it, so it was easy to modify. In the assembly
> I allocated 16 megabytes of static storage (using the .space
> keyword),
> first in the .data section, then in .rodata, then in .text. The
> .text section is where code exists. In no case did the module take
> more than 1/4 second to load. In all cases the size shown by
> `lsmod`
> reflected the enormous size of the module.
> 
> Now, that's static storage. If your code uses kmalloc() and
> friends to allocate a lot of storage when it is being loaded,
> then that's a different story. FYI, when you see a kernel message
> on the screen, that's not necessarily when it was "printed". It
> gets buffered, you know. If you want to time-check when various
> sections get control, to find out what's eating the time, then
> put the jiffie count into your kernel messages.
> 
> A simple macro using the __FUNCTION__ string and the jiffie
> count can go a long way towards finding out what's happening.
> 
> For instance, I once had a problem with continuous interrupts
> from a device, that couldn't be cleared, until the device was
> initialized. That slowed the system to a stand-still until
> I found that. The fix was easy, do some initialization before
> attaching the interrupt, at least enough to quiet the board.
> This board had an empty FPGA, whos bits need to be loaded
> with a bit-banger to make it work. The pin connected to an
> interrupt was just whatever-it-was-from-the-factory, before
> the intelligence was loaded. That system took about a minute
> for the first kernel message to be printed. Sometimes the
> system was very quiet <forever> and needed to be kicked.
> 
> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.13 on an i686 machine (5589.55
> BogoMips).
> Warning : 98.36% of all statistics are fiction.
> 
> ****************************************************************
> The information transmitted in this message is confidential and may
> be privileged.  Any review, retransmission, dissemination, or other
> use of this information by persons or entities other than the
> intended recipient is prohibited.  If you are not the intended
> recipient, please notify Analogic Corporation immediately - by
> replying to this message or by sending an email to
> DeliveryErrors@analogic.com - and destroy all copies of this
> information, including any attachments, without reading or
> disclosing them.
> 
> Thank you.

Appreciate your advice and help. I finally tracked it down to the
function called in init_module() in kernel/module.c.
 
/* Allow arches to frob section contents and sizes.  */
err = module_frob_arch_sections(hdr, sechdrs, secstrings, mod);

which takes most of time (more then 99%) during module loading just
as the reply from Semuel earlier.

Wilson Li
 



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: Slow loading big kernel module in 2.6 on PPC platform

[linux-os (Dick Johnson)]

On Thu, 29 Sep 2005, Wilson Li wrote:

>
>
>> --- "linux-os (Dick Johnson)" <linux-os@analogic.com> wrote:
>>
>> On Wed, 28 Sep 2005, Wilson Li wrote:
>>
>> I have a module I am currently working on. It has some assembly
>> stuff linked with it, so it was easy to modify. In the assembly
>> I allocated 16 megabytes of static storage (using the .space
>> keyword),
>> first in the .data section, then in .rodata, then in .text. The
>> .text section is where code exists. In no case did the module take
>> more than 1/4 second to load. In all cases the size shown by
>> `lsmod`
>> reflected the enormous size of the module.
>>
>> Now, that's static storage. If your code uses kmalloc() and
>> friends to allocate a lot of storage when it is being loaded,
>> then that's a different story. FYI, when you see a kernel message
>> on the screen, that's not necessarily when it was "printed". It
>> gets buffered, you know. If you want to time-check when various
>> sections get control, to find out what's eating the time, then
>> put the jiffie count into your kernel messages.
>>
>> A simple macro using the __FUNCTION__ string and the jiffie
>> count can go a long way towards finding out what's happening.
>>
>> For instance, I once had a problem with continuous interrupts
>> from a device, that couldn't be cleared, until the device was
>> initialized. That slowed the system to a stand-still until
>> I found that. The fix was easy, do some initialization before
>> attaching the interrupt, at least enough to quiet the board.
>> This board had an empty FPGA, whos bits need to be loaded
>> with a bit-banger to make it work. The pin connected to an
>> interrupt was just whatever-it-was-from-the-factory, before
>> the intelligence was loaded. That system took about a minute
>> for the first kernel message to be printed. Sometimes the
>> system was very quiet <forever> and needed to be kicked.
>>
>>
>> Cheers,
>> Dick Johnson
>> Penguin : Linux version 2.6.13 on an i686 machine (5589.55
>> BogoMips).
>> Warning : 98.36% of all statistics are fiction.
>>
>> ****************************************************************
>> The information transmitted in this message is confidential and may
>> be privileged.  Any review, retransmission, dissemination, or other
>> use of this information by persons or entities other than the
>> intended recipient is prohibited.  If you are not the intended
>> recipient, please notify Analogic Corporation immediately - by
>> replying to this message or by sending an email to
>> DeliveryErrors@analogic.com - and destroy all copies of this
>> information, including any attachments, without reading or
>> disclosing them.
>>
>> Thank you.
>
> Appreciate your advice and help. I finally tracked it down to the
> function called in init_module() in kernel/module.c.
>
> /* Allow arches to frob section contents and sizes.  */
> err = module_frob_arch_sections(hdr, sechdrs, secstrings, mod);
>
> which takes most of time (more then 99%) during module loading just
> as the reply from Semuel earlier.
>
> Wilson Li
>

Yes. Look at the code in .../arch/ppc/kernel/module.c count_relocs()
and you will see a quadratic (n ^2) example of how not to do something!

This probably could be fixed as (n * 2) order, two passes, however in
the meantime, you might want to make as many symbols as you can in
your code static. Because of the quadratic relationship, a small
change in the number of symbols will make a large change in the
load-time!

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Slow loading big kernel module in 2.6 on PPC platform

[Bill Davidsen]

Wilson Li wrote:
> Hi,
> 
> I am trying to port several third party kernel modules from kernel
> 2.4 to 2.6 on a ppc (MPC824x) platform. For small size of modules, it
> works perfectly in 2.6. But there's one huge kernel module which size
> is about 2.7M bytes (size reported by lsmod after insmod), and it
> takes about 90 seconds to load this module before init_module starts.
> I did not notice there's such obvious delay in 2.4 kernel.

How big is the module on disk? That is, what is the disk to memory 
transfer size. Really 2.7MB, or is there a lot of uninitialized storage?
-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Slow loading big kernel module in 2.6 on PPC platform

[Wilson Li]

--- Bill Davidsen <davidsen@tmr.com> wrote:

> Wilson Li wrote:
> > Hi,
> > 
> > I am trying to port several third party kernel modules from
> kernel
> > 2.4 to 2.6 on a ppc (MPC824x) platform. For small size of
> modules, it
> > works perfectly in 2.6. But there's one huge kernel module which
> size
> > is about 2.7M bytes (size reported by lsmod after insmod), and it
> > takes about 90 seconds to load this module before init_module
> starts.
> > I did not notice there's such obvious delay in 2.4 kernel.
> 
> How big is the module on disk? That is, what is the disk to memory 
> transfer size. Really 2.7MB, or is there a lot of uninitialized
> storage?
> -- 
>     -bill davidsen (davidsen@tmr.com)

The original module size on disk is around 3.3M bytes. Here's details
of size.

   text    data     bss     dec     hex filename
2025644  263244  213024 2501912  262d18 mrbig.ko

Thanks,
Wilson Li


	
		
______________________________________________________ 
Yahoo! for Good 
Donate to the Hurricane Katrina relief effort. 
http://store.yahoo.com/redcross-donate3/ 

Re: Slow loading big kernel module in 2.6 on PPC platform

[Arjan van de Ven]

> The original module size on disk is around 3.3M bytes. Here's details
> of size.
> 
>    text    data     bss     dec     hex filename
> 2025644  263244  213024 2501912  262d18 mrbig.ko

wow that is a whole lot of GPL code ;)

Re: Slow loading big kernel module in 2.6 on PPC platform

[Samuel Masham]

> Wilson Li wrote:
> > Hi,
> > 
> > I am trying to port several third party kernel modules from
> kernel
> > 2.4 to 2.6 on a ppc (MPC824x) platform. For small size of
> modules, it
> > works perfectly in 2.6. But there's one huge kernel module which
> size
> > is about 2.7M bytes (size reported by lsmod after insmod), and it
> > takes about 90 seconds to load this module before init_module
> starts.
> > I did not notice there's such obvious delay in 2.4 kernel.

I assume you are on a slow ppc32 platform.

The time taken is a function of the number of symbols, you can work around it 
as shown in the patch below. Obviously this is just an example patch and is
NOT signed off for anything but reading :)

I would really like do some work on a pre-link for modules but don't really know 
where to start.

Any hints?

Samuel

ps Not subscribed, just  so please cc me

diff -ru src.orig/include/linux/moduleparam.h src/include/linux/moduleparam.h
--- src.orig/include/linux/moduleparam.h
+++ src/include/linux/moduleparam.h
@@ -85,6 +85,11 @@
 		      unsigned num,
 		      int (*unknown)(char *param, char *val));
 
+
+struct module;
+
+extern int parse_args_reloc(char ** args, struct module * me, int * core_size, int * init_size);
+
 /* All the helper functions */
 /* The macros to do compile-time type checking stolen from Jakub
    Jelinek, who IIRC came up with this idea for the 2.4 module init code. */
diff -ru src.orig/kernel/module.c src/kernel/module.c
--- src.orig/kernel/module.c
+++ src/kernel/module.c
@@ -1429,6 +1429,8 @@
 }
 #endif /* CONFIG_KALLSYMS */
 
+
+
 /* Allocate and load the module: note that size of section 0 is always
    zero, and we rely on this for optional sections. */
 static struct module *load_module(void __user *umod,
@@ -1446,7 +1448,9 @@
 	long err = 0;
 	void *percpu = NULL, *ptr = NULL; /* Stops spurious gcc warning */
 	struct exception_table_entry *extable;
-
+	int no_frob_arch_sections = 0;
+	int core_size=0, init_size=0;
+ 
 	DEBUGP("load_module: umod=%p, len=%lu, uargs=%p¥n",
 	       umod, len, uargs);
 	if (len < sizeof(*hdr))
@@ -1579,8 +1583,25 @@
 
 	mod->state = MODULE_STATE_COMING;
 
-	/* Allow arches to frob section contents and sizes.  */
-	err = module_frob_arch_sections(hdr, sechdrs, secstrings, mod);
+	if(strncmp("elf_plt_info=",args, strlen("elf_plt_info="))==0){
+		if(parse_args_reloc(&args, mod, &core_size, &init_size)) {
+			/* Allow passing hard coded relocation sizes. */
+			sechdrs[mod->arch.core_plt_section].sh_size = core_size;
+			sechdrs[mod->arch.init_plt_section].sh_size = init_size;
+			no_frob_arch_sections = 1;
+		} 	
+	}
+	
+	if(!no_frob_arch_sections) 
+	{
+		/* Allow arches to frob section contents and sizes.  */
+		err = module_frob_arch_sections(hdr, sechdrs, secstrings, mod);
+		printk("init_module: consider ¥"insmod %s elf_plt_info=%d,%d,%d,%d %s¥"¥n", mod->name,
+			mod->arch.core_plt_section, mod->arch.init_plt_section,
+			sechdrs[mod->arch.core_plt_section].sh_size, sechdrs[mod->arch.init_plt_section].sh_size, args);
+	}
+
+
 	if (err < 0)
 		goto free_mod;
 
diff -ru src.orig/kernel/params.c src/kernel/params.c
--- src.orig/kernel/params.c
+++ src/kernel/params.c
@@ -164,6 +164,17 @@
 	return 0;
 }
 
+
+int parse_args_reloc(char ** args, struct module *me, int* core_size, int* init_size){
+	char *param, *val;
+	int ret=0;
+	*args = next_arg(*args, &param, &val);//args pointing to next of elf_plt_info=x,y.z,v
+	ret = sscanf(val, "%d,%d,%d,%d",	
+		&me->arch.core_plt_section, &me->arch.init_plt_section, core_size, init_size);
+	if(ret!=4) return 0;  /* fail */
+        return 1;             /* success */
+}
+
 /* Lazy bastard, eh? */
 #define STANDARD_PARAM_DEF(name, type, format, tmptype, strtolfn)      	¥
 	int param_set_##name(const char *val, struct kernel_param *kp)	¥

Re: Slow loading big kernel module in 2.6 on PPC platform

[Wilson Li]

--- Samuel Masham <Samuel.Masham@jp.sony.com> wrote:

> I assume you are on a slow ppc32 platform.
> 
> The time taken is a function of the number of symbols, you can work
> around it 
> as shown in the patch below. Obviously this is just an example
> patch and is
> NOT signed off for anything but reading :)
> 
> I would really like do some work on a pre-link for modules but
> don't really know 
> where to start.
> 
> Any hints?
> 
> Samuel
> 
> ps Not subscribed, just  so please cc me
> 

Appreciate your help. 
I applied your patch manually since something was wrong during
patching. I guess we might not use same version of kernel. Mine is
2.6.8. 

But the function parse_args_reloc() still failed even though I have
passed a module param like elf_plt_info=1 during insmod. Here's the
command to load the module.

#>insmod mrbig.ko elf_plt_info=1

And console output is: 
init_module: consider insmod mrbig elf_plt_info=25,27,322144,160

I have no idea what the plt section is and what is going on in
module_frob_arch_sections() function. Any hints or documents I can
refer to?

Thanks,
Wilson Li




		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: Slow loading big kernel module in 2.6 on PPC platform

[Wilson Li]

I think I got what you are trying to do in your patch. This is really
a smart workaround. At least it works for me for now, it just need
the module to be loaded first to generate all the infos which takes
time. And then use the infos pre-calculated to load the module just
like
#>insmod mrbig.ko elf_plt_info=25,27,322144,160

Thanks and really appreciate your help.
Wilson Li 

--- Wilson Li <yongshenglee@yahoo.com> wrote:

> 
> 
> --- Samuel Masham <Samuel.Masham@jp.sony.com> wrote:
> 
> > I assume you are on a slow ppc32 platform.
> > 
> > The time taken is a function of the number of symbols, you can
> work
> > around it 
> > as shown in the patch below. Obviously this is just an example
> > patch and is
> > NOT signed off for anything but reading :)
> > 
> > I would really like do some work on a pre-link for modules but
> > don't really know 
> > where to start.
> > 
> > Any hints?
> > 
> > Samuel
> > 
> > ps Not subscribed, just  so please cc me
> > 
> 
> Appreciate your help. 
> I applied your patch manually since something was wrong during
> patching. I guess we might not use same version of kernel. Mine is
> 2.6.8. 
> 
> But the function parse_args_reloc() still failed even though I have
> passed a module param like elf_plt_info=1 during insmod. Here's the
> command to load the module.
> 
> #>insmod mrbig.ko elf_plt_info=1
> 
> And console output is: 
> init_module: consider insmod mrbig elf_plt_info=25,27,322144,160
> 
> I have no idea what the plt section is and what is going on in
> module_frob_arch_sections() function. Any hints or documents I can
> refer to?
> 
> Thanks,
> Wilson Li
> 
> 
> 
> 
> 		
> __________________________________ 
> Yahoo! Mail - PC Magazine Editors' Choice 2005 
> http://mail.yahoo.com
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: Slow loading big kernel module in 2.6 on PPC platform

[Wilson Li]

--- Samuel Masham <Samuel.Masham@jp.sony.com> wrote:

> > Wilson Li wrote:
> > > Hi,
> > > 
> > > I am trying to port several third party kernel modules from
> > kernel
> > > 2.4 to 2.6 on a ppc (MPC824x) platform. For small size of
> > modules, it
> > > works perfectly in 2.6. But there's one huge kernel module
> which
> > size
> > > is about 2.7M bytes (size reported by lsmod after insmod), and
> it
> > > takes about 90 seconds to load this module before init_module
> > starts.
> > > I did not notice there's such obvious delay in 2.4 kernel.
> 
> I assume you are on a slow ppc32 platform.
> 
> The time taken is a function of the number of symbols, you can work
> around it 
> as shown in the patch below. Obviously this is just an example
> patch and is
> NOT signed off for anything but reading :)
> 
> I would really like do some work on a pre-link for modules but
> don't really know 
> where to start.
> 
> Any hints?
> 
> Samuel
> 
> ps Not subscribed, just  so please cc me
> 

Here's my two cents.

1. Add time-consuming get_plt_size() functionality to
scripts/mod/modpost.c (per arch), and calculate the size when
scripts/mod/modpost is called to generate mymodule.mod.c during
making of kernel module.

2. How to pass this info down to sys_init_module() in kernel? Maybe
we can add a special section in mymodule.mod.c. So this info will be
part of mymodule.ko and parsed by sys_init_module() later.

Then it won't make too much impact on the build process.

Sounds easy;-) Hopefully it'll work.

Wilson Li







	
		
______________________________________________________ 
Yahoo! for Good 
Donate to the Hurricane Katrina relief effort. 
http://store.yahoo.com/redcross-donate3/