← Back to context

Comment by o11c

3 days ago

For a long time, one of the major problems with alternate allocators is that they would never return free memory back to the OS, just keep the dirty pages in the process. This did eventually change, but it remains a strong indicator of different priorities.

There's also the fact that ... a lot of processes only ever have a single thread, or at most have a few background threads that do very little of interest. So all these "multi-threading-first allocators" aren't actually buying anything of value, and they do have a lot of overhead.

Semi-related: one thing that most people never think about: it is exactly the same amount of work for the kernel to zero a page of memory (in preparation for a future mmap) as for a userland process to zero it out (for its own internal reuse)

8 comments

o11c

Reply
senderista  3 days ago

> Semi-related: one thing that most people never think about: it is exactly the same amount of work for the kernel to zero a page of memory (in preparation for a future mmap) as for a userland process to zero it out (for its own internal reuse)

Possibly more work since the kernel can't use SIMD

  • LtdJorge  3 days ago

    Why is that? Doesn't Linux use SIMD for the crypto operations?

    • dwattttt  2 days ago

      Allowing SIMD instructions to be used arbitrarily in kernel actually has a fair penalty to it. I'm not sure what Linux does specifically, but:

      When a syscall is made, the kernel has to backup the user mode state of the thread, so it can restore it later.

      If any kernel code could use SIMD registers, you'll have to backup and restore that too, and those registers get big. You could easily be looking at adding a 1kb copy to every syscall, and most of the time it wouldn't be needed.

      3 replies →

vlovich123  3 days ago

That’s actually particular try to alternate allocators and not true for glibc if I recall correctly (it’s much worse at returning memory).