Interest is supporting mbind
ollie-etl opened this issue · 10 comments
The api currently allows us to madvise memory maps. Would there be an interest in also providing an mbind functionality?
If someone is willing to implement it - sure.
I am, it save the hacks i've currently got in place. The headache is either upstreaming the mbind call to libc, or using syscall here directly
The headache is either upstreaming the mbind call to libc, or using syscall here directly
I think as a third option, you could also just put the prototype of the libc function into this crate until the upstreaming is complete. (We do use the same approach for the Windows API calls used here for example.)
There is no libc function for mbind, it involves either using libnuma, or calling syscall directly, with the appropriate op. As that's all libnuma does, i think the latter is preferable.
Then I guess this is out of scope.
How do you feel about a dependency on the syscalls crate?
You end up with something like this (different function):
pub fn get_mem_policy() -> Result<(i32, [usize; 1]), Errno> {
let mut mode: i32 = 0;
let mut node_mask: [usize; 1] = [0; 1];
unsafe {
syscall5(
Sysno::get_mempolicy,
((&mut mode) as *mut i32) as usize,
node_mask.as_mut_ptr() as usize,
8 * std::mem::size_of::<usize>(),
0,
0,
)
}
.map(drop);
Ok((mode, node_mask))
}It's way out of scope. This crate is for memory mapping only.
its exactly the same rational as mlock and madvise, both of which have apis: you'd like to control some aspect of the mapping, in this case its allocation onto a specific numa node. Ignore the get_mem_policy - that was to highlight the use of syscalls directly, not a function we'd nessesarily use
madvice is in libc. And it already caused too many problems. I'm not interested in maintaining more features.
understood. Closing this issue.