LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Jan-Bernd Themann <ossthema@de.ibm.com>
Cc: linuxppc-dev@ozlabs.org, Christoph Raisch <RAISCH@de.ibm.com>,
	Thomas Q Klein <TKLEIN@de.ibm.com>,
	ossthema@linux.vnet.ibm.com,
	Jan-Bernd Themann <THEMANN@de.ibm.com>, Greg KH <greg@kroah.com>,
	apw <apw@uk.ibm.com>, linux-kernel <linux-kernel@vger.kernel.org>,
	Badari Pulavarty <pbadari@us.ibm.com>,
	netdev <netdev@vger.kernel.org>,
	tklein@linux.ibm.com
Subject: Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
Date: Wed, 20 Feb 2008 10:14:02 -0800	[thread overview]
Message-ID: <1203531242.15017.20.camel@nimitz.home.sr71.net> (raw)
In-Reply-To: <200802181100.12995.ossthema@de.ibm.com>

On Mon, 2008-02-18 at 11:00 +0100, Jan-Bernd Themann wrote:
> Dave Hansen <haveblue@us.ibm.com> wrote on 15.02.2008 17:55:38:
> 
> > I've been thinking about that, and I don't think you really *need* to
> > keep a comprehensive map like that. 
> > 
> > When the memory is in a particular configuration (range of memory
> > present along with unique set of holes) you get a unique ehea_bmap
> > configuration.  That layout is completely predictable.
> > 
> > So, if at any time you want to figure out what the ehea_bmap address for
> > a particular *Linux* virtual address is, you just need to pretend that
> > you're creating the entire ehea_bmap, use the same algorithm and figure
> > out host you would have placed things, and use that result.
> > 
> > Now, that's going to be a slow, crappy linear search (but maybe not as
> > slow as recreating the silly thing).  So, you might eventually run into
> > some scalability problems with a lot of packets going around.  But, I'd
> > be curious if you do in practice.
> 
> Up to 14 addresses translation per packet (sg_list) might be required on 
> the transmit side. On receive side it is only 1. Most packets require only 
> very few translations (1 or sometimes more)  translations. However, 
> with more then 700.000 packets per second this approach does not seem 
> reasonable from performance perspective when memory is fragmented as you
> described.

OK, but let's see the data.  *SHOW* me that it's slow. If the algorithm
works, then perhaps we can simply speed it up with a little caching and
*MUCH* less memory overhead.

-- Dave


  reply	other threads:[~2008-02-20 18:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-11 16:24 Jan-Bernd Themann
2008-02-11 16:47 ` Dave Hansen
2008-02-13 15:17   ` Jan-Bernd Themann
2008-02-13 17:05     ` Dave Hansen
2008-02-14  8:46     ` Christoph Raisch
2008-02-14 17:12       ` Dave Hansen
2008-02-14 17:36         ` Badari Pulavarty
2008-02-14 17:38           ` Dave Hansen
2008-02-15 13:22         ` Christoph Raisch
2008-02-15 16:55           ` Dave Hansen
2008-02-18 10:00             ` Jan-Bernd Themann
2008-02-20 18:14               ` Dave Hansen [this message]
2008-02-11 16:50 ` Dave Hansen
2008-02-12 18:04 ` Dave Hansen
  -- strict thread matches above, loose matches on Subject: below --
2008-02-11 15:57 Jan-Bernd Themann
2008-02-11 16:02 ` Sam Ravnborg
2008-02-11 16:04 ` Dave Hansen

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=1203531242.15017.20.camel@nimitz.home.sr71.net \
    --to=haveblue@us.ibm.com \
    --cc=RAISCH@de.ibm.com \
    --cc=THEMANN@de.ibm.com \
    --cc=TKLEIN@de.ibm.com \
    --cc=apw@uk.ibm.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=ossthema@de.ibm.com \
    --cc=ossthema@linux.vnet.ibm.com \
    --cc=pbadari@us.ibm.com \
    --cc=tklein@linux.ibm.com \
    --subject='Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier' \
    /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

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).