Messages in this thread | | | From | (Victor Yodaiken) | Date | Fri, 8 Aug 1997 16:57:49 -0600 | Subject | Re: Kernel virtual memory? |
| |
On Aug 8, 5:16pm, Mark Hemment wrote: Subject: Re: Kernel virtual memory? > "rt becomes impossible on Linux". Wow, strong statement!! > As I've said, there are not many allocations which need contigious/DMA >pages. Not all flush_tlb_page(), cause a call to smp_flush_tlb(). > A smp_flush_tlb() is expensive, and to be avoid then every possible, but >it certainly not going to make RT impossible. Infact, better memory >management makes RT more do-able.
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.
| |