From: Keith Owens <kaos@ocs.com.au>
To: hirao <hirao@estartu.open.nm.fujitsu.co.jp>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] enhance kernel profiling to loadable modules
Date: Thu, 21 Mar 2002 16:02:48 +1100 [thread overview]
Message-ID: <2761.1016686968@kao2.melbourne.sgi.com> (raw)
In-Reply-To: Your message of "Wed, 20 Mar 2002 17:04:08 +0900." <20020320165324.E98F.HIRAO@estartu.open.nm.fujitsu.co.jp>
On Wed, 20 Mar 2002 17:04:08 +0900,
hirao <hirao@estartu.open.nm.fujitsu.co.jp> wrote:
>These are a kernel patch I wrote to enhance kernel profiling to loadable modules and
>a patch which adds a new command READPROFILE to util-linux.
>diff -Naur linux-2.4.18/kernel/module.c linux-2.4.18new/kernel/module.c
>--- linux-2.4.18/kernel/module.c Mon Nov 12 04:23:14 2001
>+++ linux-2.4.18new/kernel/module.c Mon Mar 18 11:31:24 2002
>@@ -10,6 +10,7 @@
> #include <linux/slab.h>
> #include <linux/kmod.h>
> #include <linux/seq_file.h>
>+#include <linux/profile.h>
>
> /*
> * Originally by Anonymous (as far as I know...)
>@@ -530,6 +531,13 @@
> }
> }
>
>+#ifdef CONFIG_MODULE_PROFILE
>+ if (create_module_profile(mod)) {
>+ printk(KERN_WARNING "init_module: creation of module "
>+ "profiling buffer failed for module(%s).\n", mod->name);
>+ }
>+#endif
Instead of patching kernel/module.c and maintaining a separate list of
module related profiling data, use the kernel_data field in struct
module. I added that field specificially so to track any kernel data
that relates to each module.
Change the module_arch_init() and free_module() functions in
include/asm-i386/module.h to allocate and free the kernel_data
structure during module load and unload. Take the profile lock in
those routines (disabling interrupts) when you update kernel_data.
To map a profile eip to a module, run the module list looking for the
address, see kernel_text_address() in arch/i386/kernel/traps.c for
example code.
With this approach, the mainline module code is unchanged, all arch
specific profile code is in include/asm-$(ARCH)/module.h.
Your srch_prof_buffer() algorithm is ix86 specific, you assume that
modules are always above the end of the kernel. That is not true on
all architectures. The correct method is to treat the kernel as just
another module and store the profile data for the kernel in
kernel_module.kernel_data, using arch_init_modules(). Running the
module list (which includes the kernel itself) will find the correct
address range in an architecture portable way. Add one extra slot to
the kernel profile table for out of range addresses.
next prev parent reply other threads:[~2002-03-21 5:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-20 8:04 hirao
2002-03-21 5:02 ` Keith Owens [this message]
2002-03-25 2:23 ` hirao
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=2761.1016686968@kao2.melbourne.sgi.com \
--to=kaos@ocs.com.au \
--cc=hirao@estartu.open.nm.fujitsu.co.jp \
--cc=linux-kernel@vger.kernel.org \
/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®