Andrey Volkov wrote:
Hello Jes and all
I try to use your allocator (gen_pool_xxx), idea of which
is a cute nice thing. But current implementation of it is
inappropriate for a _device_ (aka onchip, like framebuffer) memory
allocation, by next reasons:
1) Device memory is expensive resource by access time and/or size cost.
So we couldn't use (usually) this memory for the free blocks lists.
2) Device memory usually have special requirement of access to it
(alignment/special insn). So we couldn't use part of allocated
blocks for some control structures (this problem solved in your
implementation, it's common remark)
3) Obvious (IMHO) workflow of mem. allocator look like:
- at startup time, driver allocate some big
(almost) static mem. chunk(s) for a control/data structures.
- during work of the device, driver allocate many small
mem. blocks with almost identical size.
such behavior lead to degeneration of buddy method and
transform it to the first/best fit method (with long seek
by the free node list).
4) The simple binary buddy method is far away from perfect for a device
due to a big internal fragmentation. Especially for a
network/mfd devices, for which, size of allocated data very
often is not a power of 2.
I start to modify your code to satisfy above demands,
but firstly I wish to know your, or somebody else, opinion.
Especially I will very happy if somebody have and could
provide to all, some device specific memory usage statistics.
Hi Andrey,
FYI, on arch/ppc/lib/rheap.c theres an implementation of a remote heap.
It is currently used for the management of freescale's CPM1 & CPM2 internal
dual port RAM.
Take a look, it might be what you have in mind.
Regards
Pantelis
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
