Re: [Xenomai-help] mlockall questions

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Philippe Gerum wrote:
 > Gilles Chanteperdrix wrote:
 > > On Thu, Apr 10, 2008 at 4:36 PM, Philippe Gerum
 > > <philippe.gerum@domain.hid> wrote:
 > >> Gilles Chanteperdrix wrote:
 > >>  > On Thu, Apr 10, 2008 at 2:53 AM, Philippe Gerum
 > >>  > <philippe.gerum@domain.hid> wrote:
 > >>  >> Robert McCullough wrote:
 > >>  >>  > Hi Gilles,
 > >>  >>  >
 > >>  >>  >   --> -----Original Message-----
 > >>  >>  >   --> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
 > >>  >>  >   --> Sent: Wednesday, April 09, 2008 3:29 PM
 > >>  >>  >   --> To: rob@domain.hid
 > >>  >>  >   --> Cc: xenomai@xenomai.org
 > >>  >>  >   --> 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...
 > >
 > 
 > #include <sys/resource.h>
 > #include <stdio.h>
 > #include <unistd.h>
 > #include <stdlib.h>
 > 
 > int main(int argc, char *argv[])
 > {
 > 	if (strcmp(argv[0], "child")) {
 > 		struct rlimit r = { .rlim_cur = 32768, .rlim_max = 32768 };
 > 		setrlimit(RLIMIT_STACK, &r);
 > 		execl(argv[0], "child", NULL);
 > 	} else {
 > 		struct rlimit r;
 > 		if (getrlimit(RLIMIT_STACK, &r) == 0)
 > 			printf("%s: stack size = %d\n", argv[0], r.rlim_cur);
 > 	}
 > 
 > 	return 0;
 > }

I had a doubt about what I wrote, just after writing it, which is why I
started doing my own testing. But I got distracted by the fact that all
the main thread stack was no longer commited. Now, I wonder, do you
think we should try to work around this behaviour in the I-pipe patch ?

-- 


					    Gilles.