On 06/30/2016 01:00 PM, Nadav Har'El wrote:
On Thu, Jun 30, 2016 at 12:31 PM, Justin Cinkelj
<[email protected] <mailto:[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.
I tried to do that, and sent patch. I added comment that it might be
possible that thread returned by find_by_id() get deleted while we are
using it. It unlikely/rare etc, but just to mention.
Another little detail - std::unordered_map<unsigned long, thread *>
thread_map used ULONG, but thread._id (and pid_t) are UINT - 8 vs 4 B.
Maybe should that be unified? Or is there a reason for ULONG usage?
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.
Yes, that's on whishlist too. I will read links, and hopefully
understand some bits.
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.
the other patch I sent.
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....
the C function would do it.
Tnx for help
Justin
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]
<mailto:osv-dev%[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.
