Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
- From: Jan-Bernd Themann <ossthema@xxxxxxxxxx>
- Date: Mon, 18 Feb 2008 11:00:11 +0100
switching to proper mail client...
Dave Hansen <haveblue@xxxxxxxxxx> 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.
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
0->0
1->0
2->0
3->0
...
100->100
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)
Regards,
Jan-Bernd & Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
- From: Dave Hansen
- Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
- References:
- [PATCH] drivers/base: export gpl (un)register_memory_notifier
- From: Jan-Bernd Themann
- Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
- From: Christoph Raisch
- Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
- From: Dave Hansen
- [PATCH] drivers/base: export gpl (un)register_memory_notifier
- Prev by Date: [PATCH 1/7] sched: cleanup old and rarely used debug features.
- Next by Date: Re: mips/bcm47xx/setup.c compile error
- Previous by thread: Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
- Next by thread: Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
- Index(es):
Relevant Pages
|