[RFC 65] Allocator-aware buffers - #65
Conversation
Signed-off-by: Nicholas Gates <nick@nickgates.com>
|
|
||
| A manual ownership vtable could support each backing type. It would also require custom reference | ||
| counting, release, and unique-owner recovery. The private backing type lets us add this later if an | ||
| `Arc` is too costly. |
There was a problem hiding this comment.
Arc is already a huge part of the runtime of scans.
| pub struct Buffer<T> { | ||
| ptr: NonNull<T>, | ||
| len: usize, | ||
| alignment: Alignment, |
There was a problem hiding this comment.
why have Alignment and Layout
|
Do you have any thought on using this to limit mem allocated for a given region? |
|
Do we know what the perf change between this and bytes will be. |
ctx.with_allocator(...) and basically direct requests through whatever allocator you're given. So the host engine and/or runtime could pass in an allocator pinned to a NUMA core. Functions that e.g. canonicalize list offsets, use them, then throw them away could configure arena allocators. And most commonly I'd expect the host engine to simply want to use a tree of allocators to track who allocated what. |
vortex-buffer is actually really well tested and benchmarked. The first PR in the stack shows a bunch of regressions for example. I believe there's just a bunch of inlining to fix up, but there shouldn't be any more allocations than with Tokio bytes. The only thing we give up is the split/unsplit functionality. But nothing uses that currently. |
I would like to avoid merging a regression to such a core part of vortex |
| pool, and limit buffer memory. `vortex-buffer` will own the allocator API and its memory. It will no | ||
| longer use `bytes::BytesMut` as its main storage type. | ||
|
|
|
I am still unsure how you would later want to limit allocations (due to memory usage) based on this API? |
| ```rust | ||
| enum BufferBacking { | ||
| Owned(Allocation), | ||
| External(Box<dyn BufferOwner>), |
There was a problem hiding this comment.
how does BufferOwner look like?
I don't want to. At least not yet. Unless you make every allocation fallible, by panicking or essentially turning it into async API, then you can't really apply back pressure. This proposal lets us track memory more than limit it. And engines will use this to spill or backpressure the actual big consumers like hash tables. |
|
going to do another deeper read later today, I want to see the PR and think about this more. |
3 participants
Summary
Checks