LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jan-Bernd Themann <firstname.lastname@example.org>
Cc: Dave Hansen <email@example.com>,
Christoph Raisch <RAISCH@de.ibm.com>,
Thomas Q Klein <TKLEIN@de.ibm.com>,
Jan-Bernd Themann <THEMANN@de.ibm.com>, Greg KH <firstname.lastname@example.org>,
apw <email@example.com>, linux-kernel <firstname.lastname@example.org>,
Badari Pulavarty <email@example.com>,
Subject: Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
Date: Mon, 18 Feb 2008 11:00:11 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
switching to proper mail client...
Dave Hansen <email@example.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
> The other idea is that you create a mapping that is precisely 1:1 with
> kernel memory. Let's say you have two sections present, 0 and 100. You
> have a high_section_index of 100, and you vmalloc() a 100 entry array.
> You need to create a *CONTIGUOUS* ehea map? Create one like this:
> EHEA_VADDR->Linux Section
> It's contiguous. Each area points to a valid Linux memory address.
> It's also discernable in O(1) to what EHEA address a given Linux address
> is mapped. You just have a couple of duplicate entries.
This has a serious issues with constraint I mentions in the previous mail:
"- MRs can have a maximum size of the memory available under linux"
The requirement is not met that the memory region must not be
larger then the available memory for that partition. The "create MR"
H_CALL will fails (we tried this and discussed with FW development)
Jan-Bernd & Christoph
next prev parent reply other threads:[~2008-02-18 10:02 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 [this message]
2008-02-20 18:14 ` Dave Hansen
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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier' \
* 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).