From: Rusty Russell <rusty@rustcorp.com.au>
To: Arjan van de Ven <arjan@infradead.org>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] modules: Take a shortcut for checking if an address is in a module
Date: Thu, 12 Jun 2008 10:20:58 +1000 [thread overview]
Message-ID: <200806121020.58881.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20080611081847.0b22079c@infradead.org>
On Thursday 12 June 2008 01:18:47 Arjan van de Ven wrote:
> On Wed, 11 Jun 2008 21:12:08 +1000
>
> Rusty Russell <rusty@rustcorp.com.au> wrote:
> > On Wednesday 11 June 2008 06:05:19 Arjan van de Ven wrote:
> > > From: Arjan van de Ven <arjan@linux.intel.com>
> > > Subject: [PATCH] modules: Take a shortcut for checking if an
> > > address is in a module
> > >
> > > Various pieces of the kernel (lockdep, latencytop, etc) tend to
> > > store backtraces, sometimes at a relatively high frequency. In
> > > itself this isn't a big performance deal (after all you're using
> > > diagnostics features), but there have been some complaints from
> > > people who have over 100 modules loaded that this is a tad too slow.
> >
> > Nothing wrong with the idea, but how about a nice
> > arch_maybe_module_addr() macro rather than ifdefs in module.c?
>
> Everytime someone says that, I go crawl under my desk and weep quietly
> for 10 minutes.
>
> Yes ifdefs aren't nice. However, arch_foo_bar_baz() is equally bad, it
> just moves the uglyness around a little. It's like multiplying the dirt
> by three and then sweeping it under 3 different carpets. Sure in your
> area the room looks clean, but the total amount of crap didn't decrease.
>
> The only half-way sane way to do arch_has_foo is using weak functions,
> but unfortunately that runs into gcc issues to the point of not being
> usable without a great amount of care... the alternatives are both
> unpleasant and overkill. We really should try to keep the arch stuff as
> small as possible; a gazillion arch_foo_bar()'s is the opposite
> direction there ;(
OK, then how about something like this in linux/module.h:
#ifndef MODULE_ADDR_MIN
#define MODULE_ADDR_MIN OUL
#endif
#ifndef MODULE_ADDR_MAX
#define MODULE_ADDR_MAX -1UL
#endif
Or, we could actually make those as variables and update them in module.c
itself. No arch changes required, and pretty easy to understand.
Cheers,
Rusty.
next prev parent reply other threads:[~2008-06-12 2:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-10 20:05 [PATCH] modules: Take a shortcut for checking if an address is in a module Arjan van de Ven
2008-06-11 11:12 ` Rusty Russell
2008-06-11 15:18 ` Arjan van de Ven
2008-06-11 18:54 ` Vegard Nossum
2008-06-18 9:57 ` Ingo Molnar
2008-06-18 10:24 ` Peter Zijlstra
2008-06-18 12:27 ` Rusty Russell
2008-06-12 0:20 ` Rusty Russell [this message]
2008-06-26 5:46 ` Rusty Russell
2008-06-26 11:48 ` Ingo Molnar
2008-06-18 10:00 ` Ingo Molnar
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=200806121020.58881.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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