Processor : P4040
Linux : 2.6.34
We have an application in which, I observed certain operations (yet to be identified, mostly can think of tlb flush) is broadcast through "smp_call_function_many" procedure. I can see this procedure top in overhead which is captured by all the linux profilers. This application monitors changes in the memory through per process flag (something like "page modified ?") and in a given interval(less than a minute) this flag is cleared and respective mm/TLB page is flushed using tlb_page* .
This page flush was previously achieved using batch flush (one call to flush out the required things) and now it is not possible as because current kernel is of 32 bit version. I have tried a few things as below and didn't see any -new- changes as in happening (maybe the observed behavior (mentioned below) is expected)
- This application is allowed to run on only one core (affined) though we have 4 cores, so tried to make the flush local (local_tlb_*) with an assumption that no broadcast will happen and smp_call* can be avoided , but with new change (flush local) also not observed any difference in behavior
- Attempted to drop/flush the whole process context using flush_tlb_mm* with an assumption in this processor we can do per process TLB invalidation, but this didn't work rather resulted in exception
Along with "smp_call*" function "doorbell_message*" also one of the high runners which is incurring high overhead in my real time system .
- Is it right, doing the flush of whole mm context when the process is healthily running
- Any alternative or similar like "batch flush" available for software maintained TLB's
- Is the "doorbell_message_" procedure call expected to happen when we have IPC between two processes running on different core ? or it has something to do with coherency stuff
Any other pointers on this regard will be helpful.
Thanks in Advance.