netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@linux-foundation.org>
To: Benjamin LaHaise <bcrl@kvack.org>
Cc: David Miller <davem@davemloft.net>,
	dada1@cosmosbay.com, netdev@vger.kernel.org
Subject: Re: [patch 1/4] network dev read_mostly
Date: Fri, 16 Mar 2007 10:03:04 -0700	[thread overview]
Message-ID: <20070316100304.4eca9907@freekitty> (raw)
In-Reply-To: <20070315131722.GH1246@kvack.org>

On Thu, 15 Mar 2007 09:17:22 -0400
Benjamin LaHaise <bcrl@kvack.org> wrote:

> On Thu, Mar 15, 2007 at 12:25:16AM -0700, David Miller wrote:
> > Could we obtain %rip relative addressing with the ELF
> > relocation approach I mentioned?
> 
> I think we can for some of the objects -- things like slab caches are 
> good candidates if we have the initialization done at init time, which 
> would actually be a very cool way of getting rid of the static slab 
> creation calls.  I'll cook something better up on the slab front.
> 
> As for other variables, many can't be rip relative as they often end up 
> pointing to addresses outside of the +/-2GB range we have there.
> 
> The main reason I came up with this was from looking at the various 
> kprobes and notifier chain overhead in common code paths.  In many 
> instances we need a single byte flag showing the feature is in use to 
> jump out of the hot path.
> 
> Then there are the selinux hooks....
> 
> 		-ben

There is an ugliness and maintenance vs performance tradeoff here.
The described implementation leaves me gagging. Is there some way
to do the same thing with ELF sections and post build processing?


-- 
Stephen Hemminger <shemminger@linux-foundation.org>

  reply	other threads:[~2007-03-16 17:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-12 21:08 [patch 0/4] more stuff for 2.6.22 Stephen Hemminger
2007-03-12 21:08 ` [patch 1/4] network dev read_mostly Stephen Hemminger
2007-03-12 21:34   ` David Miller
2007-03-13  5:37   ` Eric Dumazet
2007-03-13 21:26     ` [RFC] Get rid of netdev_nit Stephen Hemminger
2007-04-21  0:02       ` David Miller
2007-03-15  2:18   ` [patch 1/4] network dev read_mostly Benjamin LaHaise
2007-03-15  4:54     ` David Miller
2007-03-15  6:28     ` Eric Dumazet
2007-03-15  7:25       ` David Miller
2007-03-15  7:42         ` Eric Dumazet
2007-03-15 13:17         ` Benjamin LaHaise
2007-03-16 17:03           ` Stephen Hemminger [this message]
2007-03-15 15:10     ` Andi Kleen
2007-03-12 21:08 ` [patch 2/4] net: make seq_operations const Stephen Hemminger
2007-03-12 21:34   ` David Miller
2007-03-12 21:08 ` [patch 3/4] net: show bound packet types Stephen Hemminger
2007-03-12 21:35   ` David Miller
2007-03-12 21:08 ` [patch 4/4] tcp: statistics not read_mostly Stephen Hemminger
2007-03-12 21:15   ` David Miller
2007-03-12 21:26     ` Stephen Hemminger
2007-03-12 21:33       ` David Miller
2007-03-13 20:09       ` Andi Kleen

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=20070316100304.4eca9907@freekitty \
    --to=shemminger@linux-foundation.org \
    --cc=bcrl@kvack.org \
    --cc=dada1@cosmosbay.com \
    --cc=davem@davemloft.net \
    --cc=netdev@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;
as well as URLs for NNTP newsgroup(s).