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
>>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
Xenomai-core mailing list