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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 8 Sep 2012 00:20:09 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Benjamin Gaignard <benjamin.gaignard@...aro.org>,
	linux-kernel@...r.kernel.org, ying.huang@...el.com,
	Benjamin Gaignard <benjamin.gaignard@...ricsson.com>,
	Staffan Mansson <staffan.mansson@...ricsson.com>
Subject: Re: [PATCH] genalloc: make possible to use a custom allocation algorithm

On Fri, Sep 7, 2012 at 11:27 PM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
> On Fri,  7 Sep 2012 11:16:33 +0200
> Benjamin Gaignard <benjamin.gaignard@...aro.org> 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@...e 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/