On Thu, Apr 10, 2008 at 5:43 PM, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 4:36 PM, Philippe Gerum > > > <[EMAIL PROTECTED]> wrote: > > > > Gilles Chanteperdrix wrote: > > > On Thu, Apr 10, 2008 at 2:53 AM, Philippe Gerum > > > <[EMAIL PROTECTED]> wrote: > > >> Robert McCullough wrote: > > >> > Hi Gilles, > > >> > > > >> > --> -----Original Message----- > > >> > --> From: Gilles Chanteperdrix [mailto:[EMAIL PROTECTED] > > >> > --> Sent: Wednesday, April 09, 2008 3:29 PM > > >> > --> To: [EMAIL PROTECTED] > > >> > --> Cc: [email protected] > > >> > --> Subject: Re: [Xenomai-help] mlockall questions > > >> > --> > > >> > --> Robert McCullough wrote: > > >> > --> > Hi, > > >> > --> > > > >> > --> > I am converting part of a C++ application to real-time. > > >> > --> > > > >> > --> > I noticed that all the Xenomai examples call > > >> > --> > mlockall(MCL_CURRENT|MCL_FUTURE) at the beginning of main > before > > >> > --> creating > > >> > --> > any real-time threads. > > >> > --> > Is calling mlockall a requirement when using Xenomai? > > >> > --> > > >> > --> Yes it is. > > >> > --> > > >> > [Robert McCullough] > > >> > OK. > > >> > --> > > > >> > --> > I have added a couple of Xenomai tasks to my C++ app. > > >> > --> > A) Without calling mlockall my application seems to run > fine but I > > >> > --> noticed > > >> > --> > in /proc/xenomai/stat that a few page faults occurred. > > >> > --> > > >> > --> Well normally your application should stop with a message > telling you > > >> > --> that you have not call mlockall. Do you happen to install a > handler > > >> > --> for > > >> > --> SIGXCPU ? > > >> > [Robert McCullough] > > >> > Yes. > > >> > --> > > >> > --> > B) When calling mlockall at the beginning of my main() I > do not see > > >> > --> any page > > >> > --> > faults but some of the C++ threads do not start. > > >> > --> > > > >> > --> > Why would mlockall cause some threads not to start? > > >> > --> > > >> > --> Well, you should check rt_task_create or pthread_create return > > >> > --> value. The usual error is that you run out of memory because > of the > > >> > --> stack size problem explained in the TROUBLESHOOTING guide. > > >> > --> > > >> > --> -- > > >> > --> > > >> > --> > > >> > --> Gilles. > > >> > [Robert McCullough] > > >> > Thanks. > > >> > Calling "ulimit -s 2048" before my application in my startup script > seems to > > >> > work fine when I am running over nfs to the Denx ELDK with a bash > shell. > > >> > But my application needs to run from a CompactFlash card running > BusyBox on > > >> > a MPC5200 and BusyBox does not seem to support the "ulimit" command. > > >> > Is there another way to set this stack limit size? > > >> > > > >> > > >> - Setting the stack size property into the attribute struct for each > new pthread > > >> your application may create: pthread_attr_setstacksize(&thattr, > stacksize); > > >> > > >> - Or passing the right stack size value to any (non-POSIX) Xenomai > API task > > >> creation service, we do enforce it (e.g. rt_task_create(), taskInit(), > > >> t_create()...). > > >> > > >> - Or calling setrlimit(RLIMIT_STACK, ...) to set a global default > value for all > > >> subsequent glibc-originated threads. This is what the ulimit command > does, actually. > > > > > > The problem of pthread_attr_setstacksize (or of setting stack size in > > > one of the various thread creation services) is that it does not work > > > for the main thread stack. So, you have to use ulimit or to call > > > setrlimit before running your application, in order to set the main > > > thread stack size. > > > > > > Now about the ulimit builtin in busybox: busybox ash shell supports > ulimit. > > > > > > > Even if you don't have any shell supporting ulimit, you just need to > create a > > small launcher that basically forks/setrlimit+execs your application. > > Errr... but you need to call setrlimit before fork, otherwise it is too > late...
It looks we are wrong. The main thread stack remains allocated on-demand, even though the process is mlocked. It must be some recent kernel evolution. -- Gilles _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
