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 _______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core