2019-06-03 05:44:46 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2005-06-22 00:15:02 +00:00
|
|
|
/*
|
2011-07-13 05:14:24 +00:00
|
|
|
* Basic general purpose allocator for managing special purpose
|
|
|
|
* memory, for example, memory that is not managed by the regular
|
|
|
|
* kmalloc/kfree interface. Uses for this includes on-device special
|
|
|
|
* memory, uncached memory etc.
|
|
|
|
*
|
|
|
|
* It is safe to use the allocator in NMI handlers and other special
|
|
|
|
* unblockable contexts that could otherwise deadlock on locks. This
|
|
|
|
* is implemented by using atomic operations and retries on any
|
|
|
|
* conflicts. The disadvantage is that there may be livelocks in
|
|
|
|
* extreme cases. For better scalability, one allocator can be used
|
|
|
|
* for each CPU.
|
|
|
|
*
|
|
|
|
* The lockless operation only works if there is enough memory
|
|
|
|
* available. If new memory is added to the pool a lock has to be
|
|
|
|
* still taken. So any user relying on locklessness has to ensure
|
|
|
|
* that sufficient memory is preallocated.
|
|
|
|
*
|
|
|
|
* The basic atomic operation of this allocator is cmpxchg on long.
|
|
|
|
* On architectures that don't have NMI-safe cmpxchg implementation,
|
|
|
|
* the allocator can NOT be used in NMI handler. So code uses the
|
|
|
|
* allocator in NMI handler should depend on
|
|
|
|
* CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG.
|
2005-06-22 00:15:02 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
2011-05-25 00:13:33 +00:00
|
|
|
#ifndef __GENALLOC_H__
|
|
|
|
#define __GENALLOC_H__
|
2013-04-29 23:17:10 +00:00
|
|
|
|
2015-11-30 02:48:52 +00:00
|
|
|
#include <linux/types.h>
|
2014-01-23 23:53:18 +00:00
|
|
|
#include <linux/spinlock_types.h>
|
2017-11-17 23:28:16 +00:00
|
|
|
#include <linux/atomic.h>
|
2014-01-23 23:53:18 +00:00
|
|
|
|
2013-04-29 23:17:10 +00:00
|
|
|
struct device;
|
|
|
|
struct device_node;
|
2015-11-30 02:48:52 +00:00
|
|
|
struct gen_pool;
|
2013-04-29 23:17:10 +00:00
|
|
|
|
genalloc: make it possible to use a custom allocation algorithm
Premit use of another algorithm than the default first-fit one. For
example a custom algorithm could be used to manage alignment requirements.
As I can't predict all the possible requirements/needs for all allocation
uses cases, I add a "free" field 'void *data' to pass any needed
information to the allocation function. For example 'data' could be used
to handle a structure where you store the alignment, the expected memory
bank, the requester device, or any information that could influence the
allocation algorithm.
An usage example may look like this:
struct my_pool_constraints {
int align;
int bank;
...
};
unsigned long my_custom_algo(unsigned long *map, unsigned long size,
unsigned long start, unsigned int nr, void *data)
{
struct my_pool_constraints *constraints = data;
...
deal with allocation contraints
...
return the index in bitmap where perform the allocation
}
void create_my_pool()
{
struct my_pool_constraints c;
struct gen_pool *pool = gen_pool_create(...);
gen_pool_add(pool, ...);
gen_pool_set_algo(pool, my_custom_algo, &c);
}
Add of best-fit algorithm function:
most of the time best-fit is slower then first-fit but memory fragmentation
is lower. The random buffer allocation/free tests don't show any arithmetic
relation between the allocation time and fragmentation but the
best-fit algorithm
is sometime able to perform the allocation when the first-fit can't.
This new algorithm help to remove static allocations on ESRAM, a small but
fast on-chip RAM of few KB, used for high-performance uses cases like DMA
linked lists, graphic accelerators, encoders/decoders. On the Ux500
(in the ARM tree) we have define 5 ESRAM banks of 128 KB each and use of
static allocations becomes unmaintainable:
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
I want to use genalloc to do dynamic allocations but I need to be able to
fine tune the allocation algorithm. I my case best-fit algorithm give
better results than first-fit, but it will not be true for every use case.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@stericsson.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-05 00:13:20 +00:00
|
|
|
/**
|
2017-08-31 15:47:22 +00:00
|
|
|
* typedef genpool_algo_t: Allocation callback function type definition
|
genalloc: make it possible to use a custom allocation algorithm
Premit use of another algorithm than the default first-fit one. For
example a custom algorithm could be used to manage alignment requirements.
As I can't predict all the possible requirements/needs for all allocation
uses cases, I add a "free" field 'void *data' to pass any needed
information to the allocation function. For example 'data' could be used
to handle a structure where you store the alignment, the expected memory
bank, the requester device, or any information that could influence the
allocation algorithm.
An usage example may look like this:
struct my_pool_constraints {
int align;
int bank;
...
};
unsigned long my_custom_algo(unsigned long *map, unsigned long size,
unsigned long start, unsigned int nr, void *data)
{
struct my_pool_constraints *constraints = data;
...
deal with allocation contraints
...
return the index in bitmap where perform the allocation
}
void create_my_pool()
{
struct my_pool_constraints c;
struct gen_pool *pool = gen_pool_create(...);
gen_pool_add(pool, ...);
gen_pool_set_algo(pool, my_custom_algo, &c);
}
Add of best-fit algorithm function:
most of the time best-fit is slower then first-fit but memory fragmentation
is lower. The random buffer allocation/free tests don't show any arithmetic
relation between the allocation time and fragmentation but the
best-fit algorithm
is sometime able to perform the allocation when the first-fit can't.
This new algorithm help to remove static allocations on ESRAM, a small but
fast on-chip RAM of few KB, used for high-performance uses cases like DMA
linked lists, graphic accelerators, encoders/decoders. On the Ux500
(in the ARM tree) we have define 5 ESRAM banks of 128 KB each and use of
static allocations becomes unmaintainable:
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
I want to use genalloc to do dynamic allocations but I need to be able to
fine tune the allocation algorithm. I my case best-fit algorithm give
better results than first-fit, but it will not be true for every use case.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@stericsson.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-05 00:13:20 +00:00
|
|
|
* @map: Pointer to bitmap
|
|
|
|
* @size: The bitmap size in bits
|
|
|
|
* @start: The bitnumber to start searching at
|
|
|
|
* @nr: The number of zeroed bits we're looking for
|
2017-08-31 15:47:22 +00:00
|
|
|
* @data: optional additional data used by the callback
|
|
|
|
* @pool: the pool being allocated from
|
genalloc: make it possible to use a custom allocation algorithm
Premit use of another algorithm than the default first-fit one. For
example a custom algorithm could be used to manage alignment requirements.
As I can't predict all the possible requirements/needs for all allocation
uses cases, I add a "free" field 'void *data' to pass any needed
information to the allocation function. For example 'data' could be used
to handle a structure where you store the alignment, the expected memory
bank, the requester device, or any information that could influence the
allocation algorithm.
An usage example may look like this:
struct my_pool_constraints {
int align;
int bank;
...
};
unsigned long my_custom_algo(unsigned long *map, unsigned long size,
unsigned long start, unsigned int nr, void *data)
{
struct my_pool_constraints *constraints = data;
...
deal with allocation contraints
...
return the index in bitmap where perform the allocation
}
void create_my_pool()
{
struct my_pool_constraints c;
struct gen_pool *pool = gen_pool_create(...);
gen_pool_add(pool, ...);
gen_pool_set_algo(pool, my_custom_algo, &c);
}
Add of best-fit algorithm function:
most of the time best-fit is slower then first-fit but memory fragmentation
is lower. The random buffer allocation/free tests don't show any arithmetic
relation between the allocation time and fragmentation but the
best-fit algorithm
is sometime able to perform the allocation when the first-fit can't.
This new algorithm help to remove static allocations on ESRAM, a small but
fast on-chip RAM of few KB, used for high-performance uses cases like DMA
linked lists, graphic accelerators, encoders/decoders. On the Ux500
(in the ARM tree) we have define 5 ESRAM banks of 128 KB each and use of
static allocations becomes unmaintainable:
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
I want to use genalloc to do dynamic allocations but I need to be able to
fine tune the allocation algorithm. I my case best-fit algorithm give
better results than first-fit, but it will not be true for every use case.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@stericsson.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-05 00:13:20 +00:00
|
|
|
*/
|
|
|
|
typedef unsigned long (*genpool_algo_t)(unsigned long *map,
|
|
|
|
unsigned long size,
|
|
|
|
unsigned long start,
|
|
|
|
unsigned int nr,
|
2019-01-03 23:26:44 +00:00
|
|
|
void *data, struct gen_pool *pool,
|
|
|
|
unsigned long start_addr);
|
genalloc: make it possible to use a custom allocation algorithm
Premit use of another algorithm than the default first-fit one. For
example a custom algorithm could be used to manage alignment requirements.
As I can't predict all the possible requirements/needs for all allocation
uses cases, I add a "free" field 'void *data' to pass any needed
information to the allocation function. For example 'data' could be used
to handle a structure where you store the alignment, the expected memory
bank, the requester device, or any information that could influence the
allocation algorithm.
An usage example may look like this:
struct my_pool_constraints {
int align;
int bank;
...
};
unsigned long my_custom_algo(unsigned long *map, unsigned long size,
unsigned long start, unsigned int nr, void *data)
{
struct my_pool_constraints *constraints = data;
...
deal with allocation contraints
...
return the index in bitmap where perform the allocation
}
void create_my_pool()
{
struct my_pool_constraints c;
struct gen_pool *pool = gen_pool_create(...);
gen_pool_add(pool, ...);
gen_pool_set_algo(pool, my_custom_algo, &c);
}
Add of best-fit algorithm function:
most of the time best-fit is slower then first-fit but memory fragmentation
is lower. The random buffer allocation/free tests don't show any arithmetic
relation between the allocation time and fragmentation but the
best-fit algorithm
is sometime able to perform the allocation when the first-fit can't.
This new algorithm help to remove static allocations on ESRAM, a small but
fast on-chip RAM of few KB, used for high-performance uses cases like DMA
linked lists, graphic accelerators, encoders/decoders. On the Ux500
(in the ARM tree) we have define 5 ESRAM banks of 128 KB each and use of
static allocations becomes unmaintainable:
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
I want to use genalloc to do dynamic allocations but I need to be able to
fine tune the allocation algorithm. I my case best-fit algorithm give
better results than first-fit, but it will not be true for every use case.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@stericsson.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-05 00:13:20 +00:00
|
|
|
|
2005-06-22 00:15:02 +00:00
|
|
|
/*
|
2006-06-23 09:03:21 +00:00
|
|
|
* General purpose special memory pool descriptor.
|
2005-06-22 00:15:02 +00:00
|
|
|
*/
|
2006-06-23 09:03:21 +00:00
|
|
|
struct gen_pool {
|
2011-07-13 05:14:24 +00:00
|
|
|
spinlock_t lock;
|
2006-06-23 09:03:21 +00:00
|
|
|
struct list_head chunks; /* list of chunks in this pool */
|
|
|
|
int min_alloc_order; /* minimum allocation order */
|
genalloc: make it possible to use a custom allocation algorithm
Premit use of another algorithm than the default first-fit one. For
example a custom algorithm could be used to manage alignment requirements.
As I can't predict all the possible requirements/needs for all allocation
uses cases, I add a "free" field 'void *data' to pass any needed
information to the allocation function. For example 'data' could be used
to handle a structure where you store the alignment, the expected memory
bank, the requester device, or any information that could influence the
allocation algorithm.
An usage example may look like this:
struct my_pool_constraints {
int align;
int bank;
...
};
unsigned long my_custom_algo(unsigned long *map, unsigned long size,
unsigned long start, unsigned int nr, void *data)
{
struct my_pool_constraints *constraints = data;
...
deal with allocation contraints
...
return the index in bitmap where perform the allocation
}
void create_my_pool()
{
struct my_pool_constraints c;
struct gen_pool *pool = gen_pool_create(...);
gen_pool_add(pool, ...);
gen_pool_set_algo(pool, my_custom_algo, &c);
}
Add of best-fit algorithm function:
most of the time best-fit is slower then first-fit but memory fragmentation
is lower. The random buffer allocation/free tests don't show any arithmetic
relation between the allocation time and fragmentation but the
best-fit algorithm
is sometime able to perform the allocation when the first-fit can't.
This new algorithm help to remove static allocations on ESRAM, a small but
fast on-chip RAM of few KB, used for high-performance uses cases like DMA
linked lists, graphic accelerators, encoders/decoders. On the Ux500
(in the ARM tree) we have define 5 ESRAM banks of 128 KB each and use of
static allocations becomes unmaintainable:
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
I want to use genalloc to do dynamic allocations but I need to be able to
fine tune the allocation algorithm. I my case best-fit algorithm give
better results than first-fit, but it will not be true for every use case.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@stericsson.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-05 00:13:20 +00:00
|
|
|
|
|
|
|
genpool_algo_t algo; /* allocation function */
|
|
|
|
void *data;
|
2015-09-04 22:47:47 +00:00
|
|
|
|
|
|
|
const char *name;
|
2005-06-22 00:15:02 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
2006-06-23 09:03:21 +00:00
|
|
|
* General purpose special memory pool chunk descriptor.
|
2005-06-22 00:15:02 +00:00
|
|
|
*/
|
2006-06-23 09:03:21 +00:00
|
|
|
struct gen_pool_chunk {
|
|
|
|
struct list_head next_chunk; /* next chunk in pool */
|
2017-11-17 23:28:16 +00:00
|
|
|
atomic_long_t avail;
|
2011-05-25 00:13:34 +00:00
|
|
|
phys_addr_t phys_addr; /* physical starting address of memory chunk */
|
2019-06-13 22:56:27 +00:00
|
|
|
void *owner; /* private data to retrieve at alloc time */
|
2013-09-11 21:21:43 +00:00
|
|
|
unsigned long start_addr; /* start address of memory chunk */
|
|
|
|
unsigned long end_addr; /* end address of memory chunk (inclusive) */
|
2006-06-23 09:03:21 +00:00
|
|
|
unsigned long bits[0]; /* bitmap for allocating memory chunk */
|
2005-06-22 00:15:02 +00:00
|
|
|
};
|
|
|
|
|
2015-11-30 02:48:52 +00:00
|
|
|
/*
|
|
|
|
* gen_pool data descriptor for gen_pool_first_fit_align.
|
|
|
|
*/
|
|
|
|
struct genpool_data_align {
|
|
|
|
int align; /* alignment by bytes for starting address */
|
|
|
|
};
|
|
|
|
|
2015-11-30 02:48:53 +00:00
|
|
|
/*
|
|
|
|
* gen_pool data descriptor for gen_pool_fixed_alloc.
|
|
|
|
*/
|
|
|
|
struct genpool_data_fixed {
|
|
|
|
unsigned long offset; /* The offset of the specific region */
|
|
|
|
};
|
|
|
|
|
2006-06-23 09:03:21 +00:00
|
|
|
extern struct gen_pool *gen_pool_create(int, int);
|
2011-05-25 00:13:34 +00:00
|
|
|
extern phys_addr_t gen_pool_virt_to_phys(struct gen_pool *pool, unsigned long);
|
2019-06-13 22:56:27 +00:00
|
|
|
extern int gen_pool_add_owner(struct gen_pool *, unsigned long, phys_addr_t,
|
|
|
|
size_t, int, void *);
|
|
|
|
|
|
|
|
static inline int gen_pool_add_virt(struct gen_pool *pool, unsigned long addr,
|
|
|
|
phys_addr_t phys, size_t size, int nid)
|
|
|
|
{
|
|
|
|
return gen_pool_add_owner(pool, addr, phys, size, nid, NULL);
|
|
|
|
}
|
|
|
|
|
2011-05-25 00:13:34 +00:00
|
|
|
/**
|
|
|
|
* gen_pool_add - add a new chunk of special memory to the pool
|
|
|
|
* @pool: pool to add new memory chunk to
|
|
|
|
* @addr: starting address of memory chunk to add to pool
|
|
|
|
* @size: size in bytes of the memory chunk to add to pool
|
|
|
|
* @nid: node id of the node the chunk structure and bitmap should be
|
|
|
|
* allocated on, or -1
|
|
|
|
*
|
|
|
|
* Add a new chunk of special memory to the specified pool.
|
|
|
|
*
|
|
|
|
* Returns 0 on success or a -ve errno on failure.
|
|
|
|
*/
|
|
|
|
static inline int gen_pool_add(struct gen_pool *pool, unsigned long addr,
|
|
|
|
size_t size, int nid)
|
|
|
|
{
|
|
|
|
return gen_pool_add_virt(pool, addr, -1, size, nid);
|
|
|
|
}
|
2006-10-02 09:17:00 +00:00
|
|
|
extern void gen_pool_destroy(struct gen_pool *);
|
2019-06-13 22:56:27 +00:00
|
|
|
unsigned long gen_pool_alloc_algo_owner(struct gen_pool *pool, size_t size,
|
|
|
|
genpool_algo_t algo, void *data, void **owner);
|
|
|
|
|
|
|
|
static inline unsigned long gen_pool_alloc_owner(struct gen_pool *pool,
|
|
|
|
size_t size, void **owner)
|
|
|
|
{
|
|
|
|
return gen_pool_alloc_algo_owner(pool, size, pool->algo, pool->data,
|
|
|
|
owner);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline unsigned long gen_pool_alloc_algo(struct gen_pool *pool,
|
|
|
|
size_t size, genpool_algo_t algo, void *data)
|
|
|
|
{
|
|
|
|
return gen_pool_alloc_algo_owner(pool, size, algo, data, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* gen_pool_alloc - allocate special memory from the pool
|
|
|
|
* @pool: pool to allocate from
|
|
|
|
* @size: number of bytes to allocate from the pool
|
|
|
|
*
|
|
|
|
* Allocate the requested number of bytes from the specified pool.
|
|
|
|
* Uses the pool allocation function (with first-fit algorithm by default).
|
|
|
|
* Can not be used in NMI handler on architectures without
|
|
|
|
* NMI-safe cmpxchg implementation.
|
|
|
|
*/
|
|
|
|
static inline unsigned long gen_pool_alloc(struct gen_pool *pool, size_t size)
|
|
|
|
{
|
|
|
|
return gen_pool_alloc_algo(pool, size, pool->algo, pool->data);
|
|
|
|
}
|
|
|
|
|
2013-11-12 23:09:52 +00:00
|
|
|
extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
|
|
|
|
dma_addr_t *dma);
|
2019-06-25 15:05:58 +00:00
|
|
|
extern void *gen_pool_dma_alloc_algo(struct gen_pool *pool, size_t size,
|
|
|
|
dma_addr_t *dma, genpool_algo_t algo, void *data);
|
|
|
|
extern void *gen_pool_dma_alloc_align(struct gen_pool *pool, size_t size,
|
|
|
|
dma_addr_t *dma, int align);
|
|
|
|
extern void *gen_pool_dma_zalloc(struct gen_pool *pool, size_t size, dma_addr_t *dma);
|
|
|
|
extern void *gen_pool_dma_zalloc_algo(struct gen_pool *pool, size_t size,
|
|
|
|
dma_addr_t *dma, genpool_algo_t algo, void *data);
|
|
|
|
extern void *gen_pool_dma_zalloc_align(struct gen_pool *pool, size_t size,
|
|
|
|
dma_addr_t *dma, int align);
|
2019-06-13 22:56:27 +00:00
|
|
|
extern void gen_pool_free_owner(struct gen_pool *pool, unsigned long addr,
|
|
|
|
size_t size, void **owner);
|
|
|
|
static inline void gen_pool_free(struct gen_pool *pool, unsigned long addr,
|
|
|
|
size_t size)
|
|
|
|
{
|
|
|
|
gen_pool_free_owner(pool, addr, size, NULL);
|
|
|
|
}
|
|
|
|
|
2011-07-13 05:14:24 +00:00
|
|
|
extern void gen_pool_for_each_chunk(struct gen_pool *,
|
|
|
|
void (*)(struct gen_pool *, struct gen_pool_chunk *, void *), void *);
|
|
|
|
extern size_t gen_pool_avail(struct gen_pool *);
|
|
|
|
extern size_t gen_pool_size(struct gen_pool *);
|
genalloc: make it possible to use a custom allocation algorithm
Premit use of another algorithm than the default first-fit one. For
example a custom algorithm could be used to manage alignment requirements.
As I can't predict all the possible requirements/needs for all allocation
uses cases, I add a "free" field 'void *data' to pass any needed
information to the allocation function. For example 'data' could be used
to handle a structure where you store the alignment, the expected memory
bank, the requester device, or any information that could influence the
allocation algorithm.
An usage example may look like this:
struct my_pool_constraints {
int align;
int bank;
...
};
unsigned long my_custom_algo(unsigned long *map, unsigned long size,
unsigned long start, unsigned int nr, void *data)
{
struct my_pool_constraints *constraints = data;
...
deal with allocation contraints
...
return the index in bitmap where perform the allocation
}
void create_my_pool()
{
struct my_pool_constraints c;
struct gen_pool *pool = gen_pool_create(...);
gen_pool_add(pool, ...);
gen_pool_set_algo(pool, my_custom_algo, &c);
}
Add of best-fit algorithm function:
most of the time best-fit is slower then first-fit but memory fragmentation
is lower. The random buffer allocation/free tests don't show any arithmetic
relation between the allocation time and fragmentation but the
best-fit algorithm
is sometime able to perform the allocation when the first-fit can't.
This new algorithm help to remove static allocations on ESRAM, a small but
fast on-chip RAM of few KB, used for high-performance uses cases like DMA
linked lists, graphic accelerators, encoders/decoders. On the Ux500
(in the ARM tree) we have define 5 ESRAM banks of 128 KB each and use of
static allocations becomes unmaintainable:
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
I want to use genalloc to do dynamic allocations but I need to be able to
fine tune the allocation algorithm. I my case best-fit algorithm give
better results than first-fit, but it will not be true for every use case.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@stericsson.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-05 00:13:20 +00:00
|
|
|
|
|
|
|
extern void gen_pool_set_algo(struct gen_pool *pool, genpool_algo_t algo,
|
|
|
|
void *data);
|
|
|
|
|
|
|
|
extern unsigned long gen_pool_first_fit(unsigned long *map, unsigned long size,
|
2015-11-30 02:48:52 +00:00
|
|
|
unsigned long start, unsigned int nr, void *data,
|
2019-01-03 23:26:44 +00:00
|
|
|
struct gen_pool *pool, unsigned long start_addr);
|
2015-11-30 02:48:52 +00:00
|
|
|
|
2015-11-30 02:48:53 +00:00
|
|
|
extern unsigned long gen_pool_fixed_alloc(unsigned long *map,
|
|
|
|
unsigned long size, unsigned long start, unsigned int nr,
|
2019-01-03 23:26:44 +00:00
|
|
|
void *data, struct gen_pool *pool, unsigned long start_addr);
|
2015-11-30 02:48:53 +00:00
|
|
|
|
2015-11-30 02:48:52 +00:00
|
|
|
extern unsigned long gen_pool_first_fit_align(unsigned long *map,
|
|
|
|
unsigned long size, unsigned long start, unsigned int nr,
|
2019-01-03 23:26:44 +00:00
|
|
|
void *data, struct gen_pool *pool, unsigned long start_addr);
|
2015-11-30 02:48:52 +00:00
|
|
|
|
genalloc: make it possible to use a custom allocation algorithm
Premit use of another algorithm than the default first-fit one. For
example a custom algorithm could be used to manage alignment requirements.
As I can't predict all the possible requirements/needs for all allocation
uses cases, I add a "free" field 'void *data' to pass any needed
information to the allocation function. For example 'data' could be used
to handle a structure where you store the alignment, the expected memory
bank, the requester device, or any information that could influence the
allocation algorithm.
An usage example may look like this:
struct my_pool_constraints {
int align;
int bank;
...
};
unsigned long my_custom_algo(unsigned long *map, unsigned long size,
unsigned long start, unsigned int nr, void *data)
{
struct my_pool_constraints *constraints = data;
...
deal with allocation contraints
...
return the index in bitmap where perform the allocation
}
void create_my_pool()
{
struct my_pool_constraints c;
struct gen_pool *pool = gen_pool_create(...);
gen_pool_add(pool, ...);
gen_pool_set_algo(pool, my_custom_algo, &c);
}
Add of best-fit algorithm function:
most of the time best-fit is slower then first-fit but memory fragmentation
is lower. The random buffer allocation/free tests don't show any arithmetic
relation between the allocation time and fragmentation but the
best-fit algorithm
is sometime able to perform the allocation when the first-fit can't.
This new algorithm help to remove static allocations on ESRAM, a small but
fast on-chip RAM of few KB, used for high-performance uses cases like DMA
linked lists, graphic accelerators, encoders/decoders. On the Ux500
(in the ARM tree) we have define 5 ESRAM banks of 128 KB each and use of
static allocations becomes unmaintainable:
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
I want to use genalloc to do dynamic allocations but I need to be able to
fine tune the allocation algorithm. I my case best-fit algorithm give
better results than first-fit, but it will not be true for every use case.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@stericsson.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-05 00:13:20 +00:00
|
|
|
|
2014-10-09 22:26:35 +00:00
|
|
|
extern unsigned long gen_pool_first_fit_order_align(unsigned long *map,
|
|
|
|
unsigned long size, unsigned long start, unsigned int nr,
|
2019-01-03 23:26:44 +00:00
|
|
|
void *data, struct gen_pool *pool, unsigned long start_addr);
|
2014-10-09 22:26:35 +00:00
|
|
|
|
genalloc: make it possible to use a custom allocation algorithm
Premit use of another algorithm than the default first-fit one. For
example a custom algorithm could be used to manage alignment requirements.
As I can't predict all the possible requirements/needs for all allocation
uses cases, I add a "free" field 'void *data' to pass any needed
information to the allocation function. For example 'data' could be used
to handle a structure where you store the alignment, the expected memory
bank, the requester device, or any information that could influence the
allocation algorithm.
An usage example may look like this:
struct my_pool_constraints {
int align;
int bank;
...
};
unsigned long my_custom_algo(unsigned long *map, unsigned long size,
unsigned long start, unsigned int nr, void *data)
{
struct my_pool_constraints *constraints = data;
...
deal with allocation contraints
...
return the index in bitmap where perform the allocation
}
void create_my_pool()
{
struct my_pool_constraints c;
struct gen_pool *pool = gen_pool_create(...);
gen_pool_add(pool, ...);
gen_pool_set_algo(pool, my_custom_algo, &c);
}
Add of best-fit algorithm function:
most of the time best-fit is slower then first-fit but memory fragmentation
is lower. The random buffer allocation/free tests don't show any arithmetic
relation between the allocation time and fragmentation but the
best-fit algorithm
is sometime able to perform the allocation when the first-fit can't.
This new algorithm help to remove static allocations on ESRAM, a small but
fast on-chip RAM of few KB, used for high-performance uses cases like DMA
linked lists, graphic accelerators, encoders/decoders. On the Ux500
(in the ARM tree) we have define 5 ESRAM banks of 128 KB each and use of
static allocations becomes unmaintainable:
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
I want to use genalloc to do dynamic allocations but I need to be able to
fine tune the allocation algorithm. I my case best-fit algorithm give
better results than first-fit, but it will not be true for every use case.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@stericsson.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-05 00:13:20 +00:00
|
|
|
extern unsigned long gen_pool_best_fit(unsigned long *map, unsigned long size,
|
2015-11-30 02:48:52 +00:00
|
|
|
unsigned long start, unsigned int nr, void *data,
|
2019-01-03 23:26:44 +00:00
|
|
|
struct gen_pool *pool, unsigned long start_addr);
|
2015-11-30 02:48:52 +00:00
|
|
|
|
genalloc: make it possible to use a custom allocation algorithm
Premit use of another algorithm than the default first-fit one. For
example a custom algorithm could be used to manage alignment requirements.
As I can't predict all the possible requirements/needs for all allocation
uses cases, I add a "free" field 'void *data' to pass any needed
information to the allocation function. For example 'data' could be used
to handle a structure where you store the alignment, the expected memory
bank, the requester device, or any information that could influence the
allocation algorithm.
An usage example may look like this:
struct my_pool_constraints {
int align;
int bank;
...
};
unsigned long my_custom_algo(unsigned long *map, unsigned long size,
unsigned long start, unsigned int nr, void *data)
{
struct my_pool_constraints *constraints = data;
...
deal with allocation contraints
...
return the index in bitmap where perform the allocation
}
void create_my_pool()
{
struct my_pool_constraints c;
struct gen_pool *pool = gen_pool_create(...);
gen_pool_add(pool, ...);
gen_pool_set_algo(pool, my_custom_algo, &c);
}
Add of best-fit algorithm function:
most of the time best-fit is slower then first-fit but memory fragmentation
is lower. The random buffer allocation/free tests don't show any arithmetic
relation between the allocation time and fragmentation but the
best-fit algorithm
is sometime able to perform the allocation when the first-fit can't.
This new algorithm help to remove static allocations on ESRAM, a small but
fast on-chip RAM of few KB, used for high-performance uses cases like DMA
linked lists, graphic accelerators, encoders/decoders. On the Ux500
(in the ARM tree) we have define 5 ESRAM banks of 128 KB each and use of
static allocations becomes unmaintainable:
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
I want to use genalloc to do dynamic allocations but I need to be able to
fine tune the allocation algorithm. I my case best-fit algorithm give
better results than first-fit, but it will not be true for every use case.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@stericsson.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-05 00:13:20 +00:00
|
|
|
|
2013-04-29 23:17:10 +00:00
|
|
|
extern struct gen_pool *devm_gen_pool_create(struct device *dev,
|
2015-09-04 22:47:43 +00:00
|
|
|
int min_alloc_order, int nid, const char *name);
|
|
|
|
extern struct gen_pool *gen_pool_get(struct device *dev, const char *name);
|
2013-04-29 23:17:10 +00:00
|
|
|
|
2014-10-09 22:26:38 +00:00
|
|
|
bool addr_in_gen_pool(struct gen_pool *pool, unsigned long start,
|
|
|
|
size_t size);
|
|
|
|
|
2013-04-29 23:17:10 +00:00
|
|
|
#ifdef CONFIG_OF
|
2015-06-30 22:00:07 +00:00
|
|
|
extern struct gen_pool *of_gen_pool_get(struct device_node *np,
|
2013-04-29 23:17:10 +00:00
|
|
|
const char *propname, int index);
|
|
|
|
#else
|
2015-06-30 22:00:07 +00:00
|
|
|
static inline struct gen_pool *of_gen_pool_get(struct device_node *np,
|
2013-04-29 23:17:10 +00:00
|
|
|
const char *propname, int index)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
#endif
|
2011-05-25 00:13:33 +00:00
|
|
|
#endif /* __GENALLOC_H__ */
|