On Thu, Jun 30, 2016 at 12:31 PM, Justin Cinkelj <[email protected]>
wrote:
> @nadav, asking for advice/guidance.
>
> One thing Open MPI does is sched_{get,set}affinity over all threads of
> current process. This is difficult in OSv as:
> - there is only one process, and "all threads" is to wide then
>
- I even can't get list of all threads belonging to Open MPI (or, after
> noticing application::unsafe_stop_and_aband()
> https://github.com/cloudius-systems/osv/blob/master/core/app.cc#L106, I
> can, but it is a bit difficult)
>
Yes, you can do something like
application::unsafe_stop_and_abandon_other_threads() does, i.e., use
sched::with_all_threads() and check each thread's app_runtime() against
this thread's.
Isn't this pretty simple to do?
- sched_getaffinity accepts only pid==0. I will send little patch to
> accept also pid==current_tid. But later, it should also accept other tids -
> will be that a problem?
>
pthread_getaffinity_np() is already not limited to the current thread.
sched_getaffinity() simply uses pthread_getaffinity_np(), so we just need
to use sched::thread::find_by_id() to convert the id to a thread (and
probably extract the part of pthread_getaffinity_np() which takes a
sched::thread(), to avoid the need to convert the sched::thread returned by
find_by_id() to a pthread).
Sounds pretty easy to do. If you need help doing that, please open an issue
about it.
However, if you also need sched_setaffinity(), this is more difficult.
Pinning the current thread, and pinning some other random thread, have
conceptual differences (e.g., consider pinning a thread which is already
running right now on the wrong CPU), and the latter hasn't been done yet.
If you need it, please checkout
https://github.com/cloudius-systems/osv/issues/520 and perhaps explain
there why you need it.
> To me, it seems that OSv equivalent of linux process is osv::application
> (ELF namespace can contain more than one app; and app_runtime has 1:1
> relationship with application I think). I would like to add (did) add list
> to track threads belonging to each app.
If the performance of this is not criticial, the exisiting solution
(with_all_threads() et al.) is good enough, isn't it?
Then we don't need to add yet another interface.
> For thread, there are sched::thread, pthread and pthread_t (and pthread
> pthread_t have 1:1: relationship too - to_libc(), from_libc()).
> osv::application already stores its primary thread in _thread, type
> pthread_t. So I choose to save list of pthread_t. But there are also
> sched::thread without corresponding pthread_t. Not a problem for me, but
> worth mentioning.
>
> Maybe list of pthread_t, stored in each app, is not needed and
> application::unsafe_stop_and_aband() approach should be used.
>
This is what I think, unless you have hundreds of apps running and want to
get more quickly the list of just one app's threads.
>
> Open MPI gets list of process threads from /proc/PID/task/TID. Should be
> that implemented? Or should be added an additional C function to just store
> TIDs in an array?
>
We can implement /proc/PID/task/TID if really important, but if you are
changing the code anyway and can call a C function, it would be easier....
>
> I attached my current patch just to illustrate what I added so far.
> Only later I realized that sched::thread has ptr to app_runtime, so there
> is no need to store list of all applications. I used app_list only to
> figure out application owning the currently destroyed thread.
>
> BR Justin
>
> --
> 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.
>
--
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.
