Re: 5 gigs of contiguos kernel VM shared with userspace

On Mon, Aug 10, 2026 at 01:32:02AM +0300, Vadim Goncharov wrote:
> Hello,
> 
> Are there ways to allocate in kernel a range of contiguous virtual address
> space, share it with userspace, and preferably run memory allocator inside
> it which has it's pointers relative to base address? Same as processes
> cooperating via mmap(), but for kernel<->user.
> 
> I'd like just run UMA inside it, but seems UMA zones cannot be told to take
> from particular range, or am I missing something? On user side, jemalloc
> mentions something like arenas, but seems it is too unprepared for even
> mmap() between processes case (may be adapting some TLSF allocator [*] is
> possible, but that's a premature question before VM one).

UMA is really two fairly distinct things: a slab allocator, and a cache.
UMA zones provide per-CPU and per-NUMA domain caches, and UMA kegs
allocate and manage slabs.

You can have a zone without a keg: if you have some collection of
objects you want to allocate to consumers, you can use
uma_zcache_create() to create a "cache zone" which provides the usual
per-CPU etc. caches to store objects returned by a custom uz_import
callback that you provide when creating the zone.  For instance, if you
have some static array of objects (i.e., there is no need to subdivide a
slab) and just want to slap a scalable cache in front of it,
uma_zcache_create() is handy.

The other thing you could do is provide a custom slab allocator for the
keg via uma_zone_set_allocf().  There, you provide some page allocator,
and you can impose whatever constraints you want.  uma_small_alloc() is
used by default for page-sized slabs, and page_alloc() is used by
default for multi-page slabs.  Your implementation could return pages
from some pre-allocated, contiguous range of memory.

> Size is not necessarily gigabytes, I expect it more often to be just megabytes
> (see ARB_* family of macros/functions), but in future can be. If it ever can be
> turned to CoW transactional semantics (think of SQLite journal, but in memory),
> it would be wonderful!
> 
> 
> [*] A paper and several implementations:
> http://www.gii.upv.es/tlsf/files/papers/ecrts04_tlsf.pdf
> https://github.com/mattconte/tlsf
> https://github.com/sysprog21/tlsf-bsd
> https://github.com/rmind/tlsf
> 
> -- 
> WBR, @nuclight
>