On Thu, 2004-08-05 at 12:26, Jan Kiszka wrote: > Philippe Gerum wrote: > >> > >>>Nope, it should not. You still have to deal with on-demand memory > >>>mappings triggering valid page faults with the "real" HAL. But you don't > >> > >>Who triggers these faults? The on-demand memory mapping. > >> > > > > > > Look at the vmalloc_fault label in > > linux/arch/i386/mm/fault.c:do_page_fault(). > > > > > >>What do you mean by on-demand memory mapping? When the heap goes out of > >>mem? I must admit, I havn't looked at the heap implementation. > >> > > > > > > This is not related to the OOM condition, but rather to some sort of > > lazy update of the task's page table by the kernel. > > > > > > Well, does this lazy page table update mean that the kernel's routine to > switch the mm (which is also used by adeos/xenomai) does not switch > everything and rather let the processor run into some fault later? Does > this also effect real-time shadow tasks? What are the side effects on > real-time domains? >
You could add LXRT and any kernel-tasks scheduler to the list. It's not an RTOS-related problem, neither it depends on the kind of task which is running, it's the way Linux has decided since ~2.4.10 IIRC to handle vmalloc/ioremap mappings. In 2.4, Adeos takes care of it so that no fault occurs (it just propagates the kernel mappings to all tasks when any change occurs). In 2.6, due to architectural changes in the kernel VM code, the fault is handled by the HAL which executes a short recovery code. The incurred cost is the time needed to process a trap #14; compared to the ~2400 ns (on fast hw) needed to program the 8254 PIT, it's not that bad (since traps are synchronous with the current code, they cannot be deferred). If you really don't want that to happen, then you still have the option to commit your memory at init time before it's used by your app, I guess. Not pretty, but well... > Jan > > _______________________________________________ > Rtai-dev mailing list > [EMAIL PROTECTED] > https://mail.gna.org/listinfo/rtai-dev -- Philippe.
