Messages in this thread | | | Date | Fri, 22 Mar 2002 14:57:45 -0800 | From | Andrew Morton <> | Subject | Re: mprotect() api overhead. |
| |
Tony.P.Lee@nokia.com wrote: > > ... > What I like to do is to use the mprotect() api to turn on/off the > memory read/write access to the globally share memory. This > way, the only possible memory corruption to the share table > is from the APIs in the libForwardTableManager.so. It makes > debugging this kind of problem easier. If the application > corrupts the memory, it will cause a seg-fault which also > makes debugging simple. > > Questions for the linux kernel guru are: > > Is this reasonable to do in Linux? > > Any idea the overhead for such scheme in term of numbers of > micro-seconds added to each API call. I like to see the > overhead in sub-microseconds range since the application > might call the api in libForwardTableManager.so at the rate > of 100k api call per seconds. > > I used the TSC counter to profile the mprotect() overhead > in QNX (micro-kernel RTOS). It has overhead is 130 > milliseconds for 6 MB of share memory which is extremely high. > I think the reason is all of QNX APIs turns to IPC messages > to process manager task. It cause context switch to > other tasks.
Seems that mprotect() against a 6 megabyte region takes five microseconds in Linux. Which is too expensive for you.
It would be better if you could map the same memory region two times. One with PROT_READ and the other with PROT_READ|PROT_WRITE. Then just use the appropriate pointer at the appropriate time.
- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |