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 ?
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
