Nice article! I wonder if now, with all the NUMA stuff and processors with hundreds of cores something changed sufficiently enough that it warrants another complete redesign similar to what happened in the article
Much of that is well addressed by one allocator arena per cpu, and either pinning threads to cpus or at least having a high threshold to move threads across NUMA boundaries.
If you have a lot of cross thread memory use, maybe you need something to help with allocate on core X, free on core Y and the cross core communication that causes (maybe that's already in place?).
There's more memory overhead that way, but large core count systems tend to have a lot of memory too.
Amongst other things (including jails), he invented the MD5crypt algorithm (originally for FreeBSD) as an alternative to the original DEScrypt of Unix:
Nice guy by the way! Met him on a train home from work once. I was working on my computer, glanced left and saw someone with a red beard running a tiling WM on some real boy system. Since we were in the silent zone, I wrote
phk?
In a text editor - got a nod, and we shook hands :)
> Reasonable people who’s opinions I respect, have called this hack anything from “brilliant” to “an afront to all morals”. I think it is OK.
It's definitely a clever hack given the constraints of malloc, but this anecdote made me smile very widely.
In addition to multi-core becoming the norm causing it to be less performant than alternatives, I imagine the "sanity checking" aspects of phkmalloc were subsumed by things like ASAN.
> Because I kept the “metadata” away from the chunks themselves, and because I used a binary “buddy” layout for sub-page-sized allocations, I could detect some of the most common mistakes.
> First I thought “We’re not having any of that” and made phkmalloc abort(2) on any wrong usage. Next time I rebooted my laptop fsck(8) aborted, and left me in single user mode until I could fix things with a floppy disk.
9 comments
[ 2.6 ms ] story [ 27.1 ms ] threadIf you have a lot of cross thread memory use, maybe you need something to help with allocate on core X, free on core Y and the cross core communication that causes (maybe that's already in place?).
There's more memory overhead that way, but large core count systems tend to have a lot of memory too.
Wow, what an incredible experience!
* https://en.wikipedia.org/wiki/Poul-Henning_Kamp
Amongst other things (including jails), he invented the MD5crypt algorithm (originally for FreeBSD) as an alternative to the original DEScrypt of Unix:
* https://en.wikipedia.org/wiki/Crypt_(C)#MD5-based_scheme
Nowadays probably most well-known for creating Varnish:
* https://en.wikipedia.org/wiki/Varnish_(software)
It's definitely a clever hack given the constraints of malloc, but this anecdote made me smile very widely.
In addition to multi-core becoming the norm causing it to be less performant than alternatives, I imagine the "sanity checking" aspects of phkmalloc were subsumed by things like ASAN.
> First I thought “We’re not having any of that” and made phkmalloc abort(2) on any wrong usage. Next time I rebooted my laptop fsck(8) aborted, and left me in single user mode until I could fix things with a floppy disk.
I love everything about this anecdote.
- "NSA Operation ORCHESTRA: Annual Status Report": https://mirrors.dotsrc.org/fosdem/2014/Janson/Sunday/NSA_ope...
- The bikeshed email: https://phk.freebsd.dk/sagas/bikeshed/