Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > Gilles Chanteperdrix 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... > > > > > > > #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 ? >
I'm not exactly sure that we should care that much about the main thread growing on demand actually. What we really want is to keep it from having all the stack space committed at once when mlocking, which is a different issue. Having on demand main stack would start biting us only if real-time code sits on top of it, which is not really a common usage pattern, since people tend to start real-time threads for that purpose. A simple test here on x86_64 (2.6.22) confirms that main threads are given a ~84Kb stack segment whatever the stack limit setting is, at least /proc/pid/maps says that. -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
