From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: rpm@xenomai.org
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] Nocow patch.
Date: Fri, 19 Jan 2007 11:10:40 +0100 [thread overview]
Message-ID: <45B09920.1040607@domain.hid> (raw)
In-Reply-To: <1169200733.3964.29.camel@domain.hid>
Philippe Gerum wrote:
> On Fri, 2007-01-19 at 10:22 +0100, Gilles Chanteperdrix wrote:
>
>>Gilles Chanteperdrix wrote:
>>
>>>However, after looking at the ARM patch, I am not so sure
>>>__ipipe_update_all_pinned_mm() is the way to go on all architectures.
>>>The ARM I-pipe handles vmalloc and ioremap faults without causing a mode
>>>switch, I wonder if it is not better than having
>>>__ipipe_update_all_pinned_mm() updating page directories all over the
>>>place.
>>
>>I checked with the I-pipe tracer the overhead on an ARM of a fault on a
>>vmalloced area: it costs around 5 us.
>>
>
>
> What is the average latency in user-space on this board for 1Khz and
> 10Khz periods?
At 10 kHz we get a lockup. At 1 kHz, we get a worst case latency around
200 us, with an average latency around 150 us if running the cache
calibrator in the background.
>
> Beyond that, we may want to keep both approaches at hand in the core
> infrastructure; running the same benchmark on, say an integrator, may
> give much higher latencies due to lousy cache issues. This still needs
> to be verified though.
My original point was that the use of ipipe_disable_ondemand_mappings
may be traumatic on cache. I am wondering if we should not add a nucleus
syscall a bit like mlockall, to which we would pass some flags like
COW_CURRENT, VMALLOC_CURRENT, VMALLOC_FUTURE, and depending on these
flags, ipipe_disable_ondemand_mappings would only do parts of what it is
currently doing.
--
Gilles Chanteperdrix
next prev parent reply other threads:[~2007-01-19 10:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-10 18:05 [Xenomai-core] Nocow patch Gilles Chanteperdrix
2007-01-11 7:38 ` Niklaus Giger
2007-01-11 8:43 ` Gilles Chanteperdrix
2007-01-11 8:46 ` Gilles Chanteperdrix
2007-01-11 15:18 ` Gilles Chanteperdrix
2007-01-13 18:57 ` Philippe Gerum
2007-01-15 10:48 ` Gilles Chanteperdrix
2007-01-19 9:22 ` Gilles Chanteperdrix
2007-01-19 9:58 ` Philippe Gerum
2007-01-19 10:10 ` Gilles Chanteperdrix [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-01-31 8:37 Gilles Chanteperdrix
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=45B09920.1040607@domain.hid \
--to=gilles.chanteperdrix@xenomai.org \
--cc=rpm@xenomai.org \
--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.