-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Question] Next steps about vtable and mmap? #359
Comments
For what it's worth, I'm also interested in a |
Hi @spl, FYI I ended up reinventing it. It's not a lot of code if |
@quark-zju Nice! Your enum Buf {
Mmap(Mmap),
Static(&'static [u8]),
Vec(Vec<u8>),
}
pub struct SharedBuf {
buf: Arc<Buf>,
offset: usize,
len: usize,
} Of course, this wasn't intended for general-purpose use as a library. |
Could impl Bytes {
pub fn from_owner(value: impl BytesOwner) -> Self { ... }
}
pub trait BytesOwner: AsRef<[u8]> + Send + Sync + 'static {} |
Here's some food for thought. Moonfire NVR currently uses a 1. mmapIt does this today, but I'm not really sure it's a good idea because of the page fault problem. As lucio-rs suggested here, it might be better to simply copy stuff from the mmaped region to a "normal" bytes rather than having a mmap-backed bytes. My current approach of not dealing with this at all means that the tokio threads may stall on page faults, which is not so great. It's really not good enough to have a bytes object for a mmap()ed region which is only special for loading and unloading, not also when reading from it. 2. more complex shared ownership / minimizing allocationstl;dr version: there's one large object Some detail, in case you're curious: mp4.rs constructs a
Here's the |
This effect may honestly not be horrible, if you're on modern hardware it should be somewhat fast. Really prolonged blocking is the issue. |
By modern hardware I assume you mean SSD? Maybe so in that case. I have terabytes of files on cheap hardware, so I use spinning disk instead. I typically assume a seek takes about 10 ms but I just benchmarked it on this system at closer to 20 ms. wikipedia says a seek took 20 ms in the 1980s so basically on this metric I might as well be using 40-year-old hardware. And even the fastest modern hard drives can't do an order of magnitude better. The physics are prohibitive. |
Haha, taking commodity hardware to a new level! You are right, you can't assume what those times might be. cc @seanmonstar on this issue since he wrote most of the vtable stuff. |
@scottlamb I have some questions about the When constructing the If immediately, what is the benefit of not closing the If lazily, how would it actually implement the |
Neither. There's not a single chunk (~ "Immediately usable"...except for the problem of file-backed chunks causing major page faults that wait for a disk seek. Unless folks have a better idea, I plan to either abandon mmap entirely or copy from a mmaped region to a heap-backed The best thing long-term IMHO would be passing around something to cause a |
Thanks for explanation. I think the |
|
I don't think I built Entity::get_range on top of streams of chunks. While I'm using hyper often will batch up my chunks into a single syscall, as you can see from strace output:
|
FYI, I stopped for this reason (see scottlamb/moonfire-nvr#88). Moonfire still uses I still do the "more complex shared ownership / minimizing allocations" thing a little but wouldn't have bothered if I had started with this |
I think you could ask the kernel to load everything at once, to avoid page fault? Copying mmap into memory sounds worse than just reading |
It was faster for me. YMMV. There are several factors. One somewhat surprising one was discussed in this article a while ago: userspace |
There's also no guarantee that your heap allocated memory will stay uncompressed in main memory, if user have enabled swapping, or configured something like zswap I think
Thanks, that makes sense. |
Closing as solved by #742. |
I have been looking for a zero-copy way of sharing mmap content via
Bytes
. I noticed the vtable feature added by #294 and didn't find follow-ups.I wonder if
bytes
is interested in getting aArc<memmap::Mmap>
version implemented (probably gated by ammap
feature that is default off). Or if other approaches are preferred (ex. expose the vtable interface and implement the mmap support in other crates).I personally think there are very limited types that meaningfully fit the vtable interface (I can hardly think of another aside from the mmap one). So it seems easier for end-users if
bytes
just implements them all (use features to keep the default deps slim). But I can see concerns aboutmemmap
being unmaintained.If the next steps are clear, I can help implementing them.
The text was updated successfully, but these errors were encountered: