On Tue, Nov 20, 2018 at 7:51 AM Waldek Kozaczuk <[email protected]> wrote:
> As I understand adding numa support to OSv is probably not a trivial task > (but maybe not as difficult?) - https://linux.die.net/man/3/numa. One of > the ffmpeg codec libraries wants to uses some of these numa functions. It > turns out that adding libnuma.so from Linux host make the codec fail > gracefully. > Indeed, code which needs libnuma.so should include that library - as it does for other libraries it needs; OSv itself should implement glibc, but not libnuma which is based on top of various more basic glibc functions and system calls. You can see an example in linux.cc, where we needed libnuma.so's get_mempolicy() to work, and that calls the __NR_get_mempolicy system call - so we implemented that. An alternative could be to decide that OSv should also implement the libnuma.so APIs on its own. But I wouldn't go doing that unless you go and read the source of this library and conclude that all it does is to call other glibc functions and system calls - and the library itself doesn't include any logic we will need to (needlessly) reproduce. > But maybe the right and fairly easy way for now would be to add > > int numa_available(void) > { > return -1; > } > > to at least clearly indicate numa support is unavailable rather than crash > with symbol missing error? > If you do add libnuma.so to your image, what fails? What I'd *expect* to see is that the application works, but thinks that there is no NUMA (all memory belongs to all cores). Doesn't that work? -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
