All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Ingo Molnar <mingo@elte.hu>
Cc: Vegard Nossum <vegard.nossum@gmail.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] modules: Take a shortcut for checking if an address is in a module
Date: Wed, 18 Jun 2008 12:24:31 +0200	[thread overview]
Message-ID: <1213784671.16944.205.camel@twins> (raw)
In-Reply-To: <20080618095711.GC15255@elte.hu>

On Wed, 2008-06-18 at 11:57 +0200, Ingo Molnar wrote:
> * Vegard Nossum <vegard.nossum@gmail.com> wrote:
> 
> > >  > > 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.
> > 
> > Would it be overkill to simply drop the module addresses in an rbtree 
> > and use that instead of a linear search over all the modules?
> > 
> > It would probably take a fair number of lines in C, and with a little 
> > memory overhead, but the speed-up should be great. Should I give it a 
> > try? (It would be arch-independent too.)
> 
> that's a tempting idea. rbtrees seem to be equally robust to plain lists 
> in my experience, so i'd not find the extra complexity a showstopper, as 
> long as the changes are well-tested. (radix trees on the other hand ... 
> ;-)

Radix trees are unsuited for this application, esp in their current
implementation.

> Rusty, Peter, Linus, any fundamental objections to Vegard's idea? Being 
> able to take a transparent stack-trace signature for debugging or 
> instrumentation purposes is important and performance does matter there 
> IMO.

A tree makes sense, although if more archs can do the same Arjan did for
x86 that'd be even better.


  reply	other threads:[~2008-06-18 10:24 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 [this message]
2008-06-18 12:27           ` Rusty Russell
2008-06-12  0:20     ` Rusty Russell
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=1213784671.16944.205.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --cc=torvalds@linux-foundation.org \
    --cc=vegard.nossum@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.