OSDN Git Service

mm/vmap: keep track of free blocks for vmap allocation
authorUladzislau Rezki (Sony) <urezki@gmail.com>
Sat, 6 Apr 2019 18:35:06 +0000 (20:35 +0200)
committer0ranko0P <ranko0p@outlook.com>
Tue, 24 Dec 2019 20:42:38 +0000 (04:42 +0800)
commitcc6cd0832165399459d8e7e0d8fc6ac8c566ec62
tree9b55a31d9873450039f500f023dc1a4b8ad00b6b
parent361a0957336a5229c67e0b96ea6e1bf1325900e5
mm/vmap: keep track of free blocks for vmap allocation

Currently an allocation of the new vmap area is done over busy
list iteration(complexity O(n)) until a suitable hole is found
between two busy areas. Therefore each new allocation causes
the list being grown. Due to over fragmented list and different
permissive parameters an allocation can take a long time. For
example on embedded devices it is milliseconds.

This patch organizes the KVA memory layout into free areas of the
1-ULONG_MAX range. It uses an augment red-black tree that keeps
blocks sorted by their offsets in pair with linked list keeping
the free space in order of increasing addresses.

Nodes are augmented with the size of the maximum available free
block in its left or right sub-tree. Thus, that allows to take a
decision and traversal toward the block that will fit and will
have the lowest start address, i.e. it is sequential allocation.

Allocation: to allocate a new block a search is done over the
tree until a suitable lowest(left most) block is large enough
to encompass: the requested size, alignment and vstart point.
If the block is bigger than requested size - it is split.

De-allocation: when a busy vmap area is freed it can either be
merged or inserted to the tree. Red-black tree allows efficiently
find a spot whereas a linked list provides a constant-time access
to previous and next blocks to check if merging can be done. In case
of merging of de-allocated memory chunk a large coalesced area is
created.

Complexity: ~O(log(N))

Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
include/linux/vmalloc.h
mm/vmalloc.c