This depends on what happens with smp_flush_tlb. If a Linux kernel
action on one processor can prevent an RT-task from running until
a synchronization is completed, then the RT system cannot assure
response and rt is impossible. RT-Linux works well because there
is a strict division of responsibilities. The rt-kernel optimizes for
worst case and Linux-proper optimizes for average case but cannot
block or pre-empt any RT activity. If "better memory management"
in Linux-proper can shuffle pages belonging to the RT side or
force a synchronization, then the careful decoupling that makes this
all possible is destroyed.
>> But this is precisely the expensive and problematic synchronization I
>> want to avoid.
>
> The ideal solution, to this and may other problems, is to place the onus
>on the exception - which should happen rarely. That is why I thought of
>removing the reference bit, to force a page-fault. What can seem ugly
>when written in words, can _sometimes_ be implemented cleanly. And it is
>the cleaness which is important.
It's a good principle of non-rt-os design to optimize the common case
and to pay a penalty on the rare case for a performance win _on average_ .
On the RT side, we cannot use this principle because a
task with a 50us period is required to run _every_ 50us, not
100us once in a while and 20us most times. The hardware will allow for
10us or less periods soon, making it possible, for example,
to directly control fine robotic motion from one or two processors
of a SMP system while Linux-proper runs on the other two processors
and on leftover time in the first two. It would be unfortunate if
a ill-considered change to memory allocation made this impossible.
> At the moment, I'm more concerned with the Fifth Ashes Test (important
>cricket match) than Memory Management :)
Best of luck.