Re: 5 gigs of contiguos kernel VM shared with userspace

On Wed, 19 Aug 2026 at 12:51, Vadim Goncharov <[email protected]> wrote:
> Of course, they can not [relied to] be same [like with two mmap-ing userspace
> processes in /general/ case], so the talk is about contiguous range in which
> addressing can be done by offset. This is a separate question, where UMA will
> likely not help me, I just combined in same msg. There are some tools able to
> work with offsets, e.g. NetBSD has https://man.netbsd.org/thmap.9 (ported from
> userland https://github.com/rmind/thmap/blob/master/src/thmap.c to
> kernel https://nxr.netbsd.org/xref/src/sys/kern/subr_thmap.c), a concurrent
> trie-hash map - generic key-value (void *key, size_t len) storage with lock-free
> lookups and fine-grained locking inserts/deletes; no hash table resizing needed
> (all automatical). But my main question was how to obtain large hunk of kernel
> memory - it's first, "how to use" is only meaningful after allocation.
>
> > Because if /that/ is OK, then you can do that with the pager interface
> > markj@ is saying and this is how
> > a lot of stuff gets exposed between userland/kernel.
>
> Are there examples? The main interface remains copyin(), I thought, which is
> exactly I want to avoid.

Anything that's doing mmap() of a device, like what sys/dev/video/ is doing.
It allocates a vm object w/ a whole array of pages, wires them down so they're
not paged out during active use, and then video_mmap_single() simply provides
the whole thing back up to userland via mmap(). There's no copyin/copyout here.


-adrian