On 2020-10-02 17:44, Claudio Imbrenda wrote:
The KVM unit tests are increasingly being used to test more than just
KVM. They are being used to test TCG, qemu I/O device emulation, other
hypervisors, and even actual hardware.
The existing memory allocators are becoming more and more inadequate to
the needs of the upcoming unit tests (but also some existing ones, see
below).
Some important features that are lacking:
* ability to perform a small physical page allocation with a big
alignment withtout wasting huge amounts of memory
* ability to allocate physical pages from specific pools/areaas (e.g.
below 16M, or 4G, etc)
* ability to reserve arbitrary pages (if free), removing them from the
free pool
Some other features that are nice, but not so fundamental:
* no need for the generic allocator to keep track of metadata
(i.e. allocation size), this is now handled by the lower level
allocators
* coalescing small blocks into bigger ones, to allow contiguous memory
freed in small blocks in a random order to be used for large
allocations again
This is achieved in the following ways:
For the virtual allocator:
* only the virtul allocator needs one extra page of metadata, but only
for allocations that wouldn't fit in one page
For the page allocator:
* page allocator has up to 6 memory pools, each pool has a metadata
area; the metadata has a byte for each page in the area, describing
the order of the block it belongs to, and whether it is free
* if there are no free blocks of the desired size, a bigger block is
split until we reach the required size; the unused parts of the block
are put back in the free lists
* if an allocation needs ablock with a larger alignment than its size, a
larger block of (at least) the required order is split; the unused parts
put back in the appropriate free lists
* if the allocation could not be satisfied, the next allowed area is
searched; the allocation fails only when all allowed areas have been
tried
* new functions to perform allocations from specific areas; the areas
are arch-dependent and should be set up by the arch code
* for now x86 has a memory area for "lowest" memory under 16MB, one for
"low" memory under 4GB and one for the rest, while s390x has one for under
2GB and one for the rest; suggestions for more fine grained areas or for
the other architectures are welcome
While doing a page allocator, the topology is not the only
characteristic we may need to specify.
Specific page characteristics like rights, access flags, cache behavior
may be useful when testing I/O for some architectures.
This obviously will need some connection to the MMU handling.
Wouldn't it be interesting to use a bitmap flag as argument to
page_alloc() to define separate regions, even if the connection with the
MMU is done in a future series?
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
