Re: [PATCH] genalloc: make possible to use a custom allocation algorithm

[Linus Walleij]

On Fri, Sep 7, 2012 at 11:27 PM, Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Fri,  7 Sep 2012 11:16:33 +0200
> Benjamin Gaignard <benjamin.gaignard@xxxxxxxxxx> wrote:

> hm, OK.  What kernel subsystem are you referring to here?  Where do I
> find this "ESRAM shared by multiple hardware"?

This is on the Ux500 in the ARM tree. We have defined the bases
for this memory down there:

cd arch/arm/mach-ux500 && grep -r ESRAM .
./include/mach/db8500-regs.h:/* Base address and bank offsets for ESRAM */
./include/mach/db8500-regs.h:#define U8500_ESRAM_BASE	0x40000000
./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK_SIZE	0x00020000
./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK0	U8500_ESRAM_BASE
./include/mach/db8500-regs.h:#define
U8500_ESRAM_BANK1	(U8500_ESRAM_BASE + U8500_ESRAM_BANK_SIZE)
./include/mach/db8500-regs.h:#define
U8500_ESRAM_BANK2	(U8500_ESRAM_BANK1 + U8500_ESRAM_BANK_SIZE)
./include/mach/db8500-regs.h:#define
U8500_ESRAM_BANK3	(U8500_ESRAM_BANK2 + U8500_ESRAM_BANK_SIZE)
./include/mach/db8500-regs.h:#define
U8500_ESRAM_BANK4	(U8500_ESRAM_BANK3 + U8500_ESRAM_BANK_SIZE)
./include/mach/db8500-regs.h:#define U8500_ESRAM_DMA_LCPA_OFFSET     0x10000
./include/mach/db8500-regs.h:#define U8500_DMA_LCPA_BASE
(U8500_ESRAM_BANK0 + U8500_ESRAM_DMA_LCPA_OFFSET)
./include/mach/db8500-regs.h:#define U8500_DMA_LCLA_BASE	U8500_ESRAM_BANK4

So 5 banks of on-chip (fast!) RAM of 128 KB each. (And my
Commodore 128 had 128 kB in total ... sob.)

As you can see the last three defines start to do something that
will grow unmaintainable: use static allocations in that ESRAM.
In this case to hold linked lists for DMA transfers.

Needless to say, a few high-performance use cases will really
benefit from using this high-speed RAM. Typically DMA
linked lists, graphics accelerators, encoders/decoders,
SETI@Home work units, you name it.

So we need to chop up this memory using a real allocator.
So we've tried to use genalloc and it turns out it works fine
until we run into allocation issues as those described by
Benjamin, and it becomes a chicken-and-egg problem
that we need fixing genalloc first to get to use the resource
in a good way before we can submit code using the
allocator.

(The rest of the review comments I think Benjamin can
answer way better than me...)

Yours,
Linus Walleij
--
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/