From: Samuel Masham <Samuel.Masham@jp.sony.com>
To: Bill Davidsen <davidsen@tmr.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Wilson Li <yongshenglee@yahoo.com>
Cc: "Yamaguchi, Yohei" <Yohei.Yamaguchi@jp.sony.com>,
Tim Bird <tim.bird@am.sony.com>
Subject: Re: Slow loading big kernel module in 2.6 on PPC platform
Date: Thu, 29 Sep 2005 10:30:38 +0900 [thread overview]
Message-ID: <200509291030.39024.Samuel.Masham@jp.sony.com> (raw)
> 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, ¶m, &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) ¥
next reply other threads:[~2005-09-29 1:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-29 1:30 Samuel Masham [this message]
2005-09-29 23:46 ` Wilson Li
2005-09-30 0:58 ` Wilson Li
2005-09-30 2:57 ` Wilson Li
-- strict thread matches above, loose matches on Subject: below --
2005-09-28 19:29 Wilson Li
2005-09-28 19:53 ` linux-os (Dick Johnson)
2005-09-28 22:27 ` Wilson Li
2005-09-29 13:04 ` linux-os (Dick Johnson)
2005-09-29 23:50 ` Wilson Li
2005-09-30 15:46 ` linux-os (Dick Johnson)
2005-09-28 20:55 ` Bill Davidsen
2005-09-28 21:37 ` Wilson Li
2005-09-29 7:36 ` Arjan van de Ven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200509291030.39024.Samuel.Masham@jp.sony.com \
--to=samuel.masham@jp.sony.com \
--cc=Yohei.Yamaguchi@jp.sony.com \
--cc=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tim.bird@am.sony.com \
--cc=yongshenglee@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®