Re: Coroutines, goroutines

On Fri, Feb 27, 2026, 8:21 PM Stelian Ionescu <[email protected]> wrote:

>
> When a fiber is created, we allocate it a single 4kB stack page, placing
> the mprotect'ed guard page next to it, but we spread these out in address
> space at, say, 256kB intervals (configurable).  Then when the guard page is
> hit, we can grow the stack without moving it.
>
>
> The resulting fragmentation of the virtual memory space will create all
> sorts of performance problems in the kernel, will prevent the use of
> hugepages (transparent or not), cause TLB pressure, etc...
>

It would prevent the use of hugepages, but I'm not convinced of your other
two claims.  Some 20 years ago, I was doing something with Scieneer CL on
Linux, and memory fragmentation was causing very severe problems.  I
gathered that the relevant kernel table was being searched linearly.  At
some point not too long after that, the table was replaced with a better
data structure, maybe a red/black tree — anyway, something with log-time
access.  Such a table is only twice as slow with a million entries as it is
with a thousand.  It's worth doing an experiment to check the performance
before heading down the road I propose, but I'll wager that it's not a
problem.

There's also no more TLB pressure in this scenario than there would be with
a less fragmented address space, assuming no hugepages in both cases.  The
TLB works on a page basis.

Do you have another idea?  Should we think harder about how to make stacks
movable?

-- Scott

_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel