> > > Hi, > > > > > > I'm still blocked on a CPU affinity problem. > > > In order to adapt a set affinity function which is based on > > > posix linux lib : > > > - CPU_AssignPID(uint32 PID, uint32 CPU_id) > > > - the cpu affinity of the caller and all its child threads > > must be set to CPU_id. > > > > > > Problems are: > > > Child PIDs must be listed, the only means I found is > > listing pids using `ls /proc/"Parent pid"/ > temp_file` > > > And each listed pid is sched_setaffinity'ed. > > > I don't know if setting affinity of RT threads from an > > other thread (parent) using pid works with xenomai. > > > > > > So, my question is : > > > With xenomai, is recursively cpu affinity setting from a > > parent thread, a good way of doing ? > > > I read switchtest program, and I conclude that in a xenomai > > and RT perspective, it seems "nicer" > > > to set affinity each threads separately during their init > > phase before the RT infinite loop. > > > Otherwise, setting affinity after child threads creation > > from its parent, may switch them into > > > secondary mode during their RT loop, and at an unknown moment. > > > Argumentation is important for my internship because I have > > to port on xenomai a very big RT > > > posix based application. And I should justify any > > modifications and prevent potential problems. > > > > > > Sorry, I don't know if it is clear. > > > > I think that it is safe to assume that if the affinity of a > thread is > > inherited from the thread that created it with Linux posix > > library, the > > same will happen with Xenomai. > > > > Now, if you want to set the affinity of a group of threads > after their > > creation, I do not see how to do this without walking > through the list > > of threads. If your library has an abstraction for threads, > > you can keep > > them in a list. It will be useful at process exit time to > > cleanly cancel > > all threads (this may be useful if you want to detect leaks > > for instance). > > > > Note that when talking about scheduling affinity function, we are > > swimming in the undefined, since these functions are not > > standardized by > > posix. > > > > But since you are porting a library to Xenomai maybe you can > > have a look > > at the current implementation of CPU_AssignPID ? > > > > -- > > Gilles Chanteperdrix > > Thanks, > Precisly, the current implementation has nothing curious and > there is no reason it does not work on xenomai but, > in a simple program that just switches the cpu : > Before CPU_assignpid call, 'ps -ax -0 SCHED | grep <pid>' > and '/proc/xenomai/sched' returns the same result (i.e. the > current thread runs on the same cpu) > After CPU_assignpid call, 'ps -ax -0 SCHED | grep <pid>' > shows that threads cpu has switched > whereas '/proc/xenomai/sched' shows no changes. > > Does '/proc/xenomai/sched' not change during running, if yes > I continue debugging my program ?
Hi, I run with gdb a test program that only create a 1 sec periodic thread that rt_timer_spin's during 10ms and waits. As above-written, when cpu is assigned _after_ child thread creation, 'ps -ax -0 SCHED | grep <pid>' shows a cpu switch on main thread whereas, '/proc/xenomai/sched' doesn't. When cpu is assigned _before_ child thread creation, 'ps -ax -0 SCHED | grep <pid>' shows a cpu switch on main thread, and '/proc/xenomai/sched' shows no changes for main thread but the child thread cpu is the assigned one. Is it right to supposed that, cpu switching is effective according to 'ps -ax -0 SCHED | grep <pid>' even in xenomai context ? Does '/proc/xenomai/sched' not change during running ? In this case, how can children threads cpu status be read dynamically like 'ps -ax -0 SCHED | grep <pid>' command for main thread ? Thanks. Niry This e-mail is intended only for the above addressee. It may contain privileged information. If you are not the addressee you must not copy, distribute, disclose or use any of the information in it. If you have received it in error please delete it and immediately notify the sender. Security Notice: all e-mail, sent to or from this address, may be accessed by someone other than the recipient, for system management and security reasons. This access is controlled under Regulation of security reasons. This access is controlled under Regulation of Investigatory Powers Act 2000, Lawful Business Practises. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
