From: Philippe Gerum <rpm@xenomai.org>
To: Jeff Weber <jweber@domain.hid>
Cc: Xenomai Help <xenomai@xenomai.org>
Subject: Re: [Xenomai-help] page faults
Date: Fri, 20 Apr 2007 19:24:51 +0200 [thread overview]
Message-ID: <1177089891.6466.24.camel@domain.hid> (raw)
In-Reply-To: <200704201143.01336.jweber@domain.hid>
On Fri, 2007-04-20 at 11:43 -0500, Jeff Weber wrote:
> On Tuesday 17 April 2007 14:17, Gilles Chanteperdrix wrote:
> > Jeff Weber wrote:
> > > On Monday 16 April 2007 16:34, Gilles Chanteperdrix wrote:
> > > > Jeff Weber wrote:
> > > > > On Monday 16 April 2007 15:43, Gilles Chanteperdrix wrote:
> > > > > > If the fault you observe is due to an access to some memory after
> > > > > > a call to fork or one of its derivative (such as system, popen,
> > > > > > etc...), the patch would have copied the whole real-time process
> > > > > > address space at fork time instead of setting up COW mappings.
> > > > >
> > > > > No process forks are involved. Though mlockall() was called from
> > > > > Linux main(), and the page fault was encountered by a separate
> > > > > Xenomai task. Here's the task history:
> > > >
> > > > The fork may well be hidden in some library. The best way to know if
> > > > there is really no fork is to register a callback with pthread_atfork.
> > >
> > > pthread_atfork confirms that there is no fork.
> >
> > Ok. I am afraid you will have to help us a bit. Could you try Xenomai
> > 2.3.1 in case the nocow patch magically solves your issue ?
> Indeed, stepping up to:
>
> linux-2.6.20.3
> xenomai-2.3.1
> ipipe-1.7-03
>
> magically solved my page faults.
Ok, so some memory which was referred to must have been lying in a COWed
shared VM page, since what 1.7-03 does is that it eagerly breaks COW for
all the virtual memory space available to real-time threads.
In case you really, really, really don't want to upgrade to 2.3.x for
product maintenance issues (albeit I would really, really, really
recommend it, because there are really, really, really nice improvements
there over 2.2.x), I've crafted a quick patch to disable ondemand VM
mappings with older Xenomai revs using recent I-pipe patches. IOW, this
patch against v2.2.x should allow you to run the latter over I-pipe
1.7-03, and make use of its COW-breaking feature (uncompiled, untested).
--- include/asm-generic/hal.h (revision 2323)
+++ include/asm-generic/hal.h (working copy)
@@ -304,6 +304,13 @@
#define PF_EVNOTIFY 0
#endif /* !PF_EVNOTIFY */
+#ifdef VM_PINNED
+#define rthal_disable_ondemand_mappings(tsk) ipipe_disable_ondemand_mappings(tsk)
+#else /* !VM_PINNED */
+/* In case the I-pipe does not allow disabling ondemand mappings. */
+#define rthal_disable_ondemand_mappings(tsk) (0)
+#endif /* !VM_PINNED */
+
#ifdef CONFIG_KGDB
#define rthal_set_foreign_stack(ipd) ipipe_set_foreign_stack(ipd)
#define rthal_clear_foreign_stack(ipd) ipipe_clear_foreign_stack(ipd)
Index: ksrc/nucleus/shadow.c
===================================================================
--- ksrc/nucleus/shadow.c (revision 2323)
+++ ksrc/nucleus/shadow.c (working copy)
@@ -828,6 +828,14 @@
thread->name, current->pid,
xnthread_base_priority(thread));
+#ifdef CONFIG_MMU
+ if (!(current->mm->def_flags & VM_LOCKED))
+ send_sig(SIGXCPU, current, 1);
+ else
+ if ((err = rthal_disable_ondemand_mappings(current)))
+ return err;
+#endif /* CONFIG_MMU */
+
/* Switch on propagation of normal kernel events for the bound
task. This is basically a per-task event filter which
restricts event notifications (e.g. syscalls) to tasks
@@ -836,11 +844,6 @@
plain (i.e. non-Xenomai) Linux tasks. */
current->flags |= PF_EVNOTIFY;
-#ifdef CONFIG_MMU
- if (!(current->mm->def_flags & VM_LOCKED))
- send_sig(SIGXCPU, current, 1);
-#endif /* CONFIG_MMU */
-
current->cap_effective |=
CAP_TO_MASK(CAP_IPC_LOCK) |
CAP_TO_MASK(CAP_SYS_RAWIO) | CAP_TO_MASK(CAP_SYS_NICE);
--
Philippe.
next prev parent reply other threads:[~2007-04-20 17:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-16 19:49 [Xenomai-help] page faults Jeff Weber
2007-04-16 20:05 ` Philippe Gerum
2007-04-16 20:20 ` Jeff Weber
2007-04-16 20:43 ` Gilles Chanteperdrix
2007-04-16 21:27 ` Jeff Weber
2007-04-16 21:34 ` Gilles Chanteperdrix
2007-04-17 13:21 ` Jeff Weber
2007-04-17 19:17 ` Gilles Chanteperdrix
2007-04-17 20:59 ` Jeff Weber
2007-04-20 16:43 ` Jeff Weber
2007-04-20 17:24 ` Philippe Gerum [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-02-28 14:22 [Xenomai-help] Page faults Jeroen Van den Keybus
2006-02-28 15:05 ` Jan Kiszka
2006-02-28 15:29 ` Jeroen Van den Keybus
2006-02-28 16:29 ` Jan Kiszka
2006-02-28 16:31 ` Philippe Gerum
2006-02-28 17:08 ` Jeroen Van den Keybus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1177089891.6466.24.camel@domain.hid \
--to=rpm@xenomai.org \
--cc=jweber@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.