Messages in this thread | | | Date | Thu, 22 Dec 2005 16:48:18 +0300 | From | Andrey Volkov <> | Subject | Re: [RFC] genalloc != generic DEVICE memory allocator |
| |
Hi Pantelis,
Pantelis Antoniou wrote: > 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
Thanks I missed it (and small wonder! :( ).
Andrew, Is somebody count HOW MANY dev specific implementation of buddy/first-fit allocators now in kernel?
-- Regards Andrey Volkov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |