Re: [Xenomai-help] isolating unwanted mode switch

[Jeff Weber <jweber@domain.hid>]

Dmitry:

On Wednesday 24 January 2007 04:08, Dmitry Adamushko wrote:
> On 23/01/07, Jeff Weber <jweber@domain.hid> wrote:
> > Dimitry:
> > > ...
> > > exceptions (CPU exceptions, e.g. page faults). I presume, you have
> > > done mlockall(CURRENT | FUTURE), haven't you?
> >
> > Yes.  my Linux application follows this this model:
> >
> > main () {
> >          mlockall(MCL_CURRENT | MCL_FUTURE);
> >         rt_task_shadow( ... )  // become a realtime thread
> >
> >         // for N threads:
> >                 rt_task_spawn( ... ) // fork off child RT thread
> > }
> >
> > It is one of the child RT threads that encounters the SIGXCPU unwanted
> > mode switch.  It this the correct way to call mlockall() ?
>
> Looks ok. Just to avoid getting into the same trap twice. You don't
> use system(), fork() or alike beasts in your code, do you?
No.

BTW, a primary mode thread in my application encountered the page fault 
writing to the BSS segment.

How would my application encounter a page fault after calling
mlockall(CURRENT | FUTURE) ?

Perhaps an answer is that mlockall() prevents pages from ever being paged out, 
but the application may still encounter page faults upon referring to pages 
that were never paged in when mlockall() was called.  If true, then my 
application may continue to encounter page faults, and hence switches to 
seondary mode until all pages in the application are loaded.

Could you, or any Linux+Xenomai memory paging expert comment on how/when pages 
for an application are loaded?

Is it possible to load all the text, bss and "initial" (initial data segment 
from ELF load image + thread stacks) data pages for an application before 
calling mlockall() ?

	thanks,
	Jeff