Re: mprotect() api overhead.

[Andrew Morton <akpm@zip.com.au>]

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.

-