From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [Xenomai-help] Standard linux assignment of processes to CPUs depends on Xenomai Config From: Philippe Gerum In-Reply-To: References: <24461688.1170430564542.JavaMail.ngmail@domain.hid> <45D97B38.6060202@domain.hid> <1171884201.9958.4.camel@domain.hid> Content-Type: text/plain Date: Mon, 19 Feb 2007 13:35:10 +0100 Message-Id: <1171888510.9958.8.camel@domain.hid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: Philippe Gerum Reply-To: rpm@xenomai.org List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dmitry Adamushko Cc: Xenomai help , Jan Kiszka On Mon, 2007-02-19 at 13:13 +0100, Dmitry Adamushko wrote: > On 19/02/07, Philippe Gerum wrote: > > On Mon, 2007-02-19 at 12:01 +0100, Dmitry Adamushko wrote: > > > Hi, > > > > > > I suppose, that's what happens. > > > > > > __xeno_sys_init() (./ksrc/nucleus/module.c) which is module_init() and > > > when compiled in -> initcall() > > > > > > calls xnarch_init() (./include/asm-i386/bits/init.h) > > > > > > This one amongst other things does > > > > > > ... > > > #ifdef CONFIG_SMP > > > /* Make sure the init sequence is kept on the same CPU when > > > running as a module. */ > > > set_cpus_allowed(current, cpumask_of_cpu(0)); > > > #endif /* CONFIG_SMP */ > > > > > > In fact, "running as a module" seems to be a bit > > > misleading here. Then another macro should be used in addition, > > > MODULE or how it's called. > > > > > > Now guess who is a "current" here? It's "init" (pid 0). > > > > > > init() -> do_basic_setup() -> do_initcalls() -> ... -> > > > __xeno_sys_init() -> xnarch_init() > > > > > > "init" is a first process to run and all the rest will inherit its > > > "cpus_allowed" field. > > > > > > That's it. > > > > > > > Eh, that's what I call a nice one Dmitry. This is the perfect example of > > legacy code stabbing us in the back. We should indeed definitely check > > for MODULE && SMP. > > Yep, as the very least. But even in this case, it's not very nice that > via cpus_allowed we affect - scheduling-wise - a process which loads > xeno modules and all its children as It's likely to be a shell. It's insmod. > I haven't looked for further details now but isn't it possible to > restore the actual state of "cpus_allowed" right after the init > sequence has been done? > Not sure, unless we explicitely ask the I-pipe to notify us when module_inits terminate. > > > > -- > > Philippe. > > > > -- Philippe.