msgpass benchmark and its refactoring dependencies #659
Conversation
| #ifdef SNMALLOC_PASS_THROUGH | ||
| struct MyAlloc | ||
| { | ||
| MyAlloc() {} | ||
| void* alloc(size_t sz) | ||
| { | ||
| return malloc(sz); | ||
| } | ||
| void dealloc(void* p) | ||
| { | ||
| free(p); | ||
| } | ||
| }; | ||
| #else | ||
| struct MyAlloc | ||
| { | ||
| snmalloc::Alloc& a; | ||
| MyAlloc() : a(ThreadAlloc::get()) {} | ||
| void* alloc(size_t sz) | ||
| { | ||
| return a.alloc(sz); | ||
| } | ||
| void dealloc(void* p) | ||
| { | ||
| a.dealloc(p); | ||
| } | ||
| }; | ||
| #endif |
There was a problem hiding this comment.
Could we just use malloc and free in the example and do something like
#ifndef SNMALLOC_PASS_THROUGH
#include <snmalloc/override/malloc.cc>
#endifI have been wondering about doing this for more of the examples, so that the tests could be less dependent on snmalloc.
There was a problem hiding this comment.
Could do. The ability to grab the thread allocator once per thread in the statically-snmalloc case seemed kind of nice (and you can get the dynamic behavior by using the malloc-passthrough and LD_PRELOAD-ing snmallocshim), but maybe it's not actually useful.
| void proxy(const struct params* param, size_t qix) | ||
| { | ||
| auto& myq = param->msgqueue[qix]; | ||
| auto& qs = param->msgqueue; | ||
|
|
||
| chatty("Px %zu q is %p\n", qix, &myq); | ||
|
|
||
| xoroshiro::p128r32 r(1234 + qix, qix); | ||
| do | ||
| { | ||
| if (myq.can_dequeue(domesticate_nop, domesticate_nop)) | ||
| { | ||
| myq.dequeue( | ||
| domesticate_nop, domesticate_nop, [qs, qix, &r](freelist::HeadPtr o) { | ||
| auto rcptqix = r.next() % qix; | ||
|
|
||
| chatty( | ||
| "Px %zu send %p to %zu\n", qix, o.as_void().unsafe_ptr(), rcptqix); | ||
|
|
||
| qs[rcptqix].enqueue(o, o, domesticate_nop); | ||
| return true; | ||
| }); | ||
| } |
There was a problem hiding this comment.
I wonder if it would be better if the proxy did a bit of deallocation, and allocation. I.e. passes some things on, deallocates somethings, and allocates new things of a different size, which it then passes on. I think we can leave as is for now, but perhaps change that in a subsequent PR.
|
Matt makes the good point that tweaking just one side of the obfuscation feels less wrong than tweaking both, so I'll make that change and force push. |
This lets us use freelists as message queues in contexts other than the remoteallocator. No functional change indended.
Approximate a message-passing application as a set of producers, a set of consumers, and a set of proxies that do both. We'll use this for some initial insight for #634 but it seems worth having in general.
This is just enough of #637 to get the benchmark itself landed, but that also pulls in the freelist refactoring and the option of tweaking obfuscation keys (but not any usage of that internally).
It's probably worth getting someone with more cryptographic and/or red-teaming chops to think about the particular tweaking function, too.