Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier

On Fri, 2008-02-15 at 14:22 +0100, Christoph Raisch wrote:
A translation from kernel to ehea_bmap space should be fast and
predictable
(ruling out hashes).
If a driver doesn't know anything else about the mapping structure,
the normal solution in kernel for this type of problem is a multi
level
look up table
like pgd->pud->pmd->pte
This doesn't sound right to be implemented in a device driver.

We didn't see from the existing code that such a mapping to a
contiguous
space already exists.
Maybe we've missed it.

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.

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.

-- Dave

--
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/

Relevant Pages

  • Re: 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree failed: The sag
    ... > usbcore: registered new driver usbfs ... (I just pulled that key at random out of the kernel repository; ... That ought to do a nice test of the CPU, memory, disk, and kernel sans ... I don't see how it could be an in-flight corruption. ...
    (Linux-Kernel)
  • Network buffer hang was Re: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata
    ... >> with a normal memory access. ... These bug doesn't cause kernel hangs, ... > network stacks allocates 4KB buffers to store this little messages. ... This means even when a driver doesn't do the rx_copybreak ...
    (Linux-Kernel)
  • Re: Memory allocation problem with 2.6.22 after suspend/resume cycle
    ... after a suspend and resume cycle, the kernel will try to free ... I do however not agree with Andrew's conclusion, as the memory is not ... Can you try another version of the ATI driver? ... Are you 100% sure that your 32-bit kernel configuration reflects the 64-bit ...
    (Linux-Kernel)
  • Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
    ... > free RAM is at 90%, still I cannot remove that piece of faulty RAM, fix ... Until we have some kind of kernel ... Another example might be a somewhat errant device driver which has ... implement these APIs it is not compatible with memory hotplug. ...
    (Linux-Kernel)
  • memory mapped IO in kernel mode
    ... I'm working on a device driver for a 2.4 kernel and I'm having a heck of a ... And I have a similar driver written for x86 ... The hardware is controlled via memory mapped registers at 0x11e0104 - ... use the handle returned by ioremap for readb and readw... ...
    (comp.os.linux.embedded)