Re: mprotect() api overhead.

Andrew Morton (akpm@zip.com.au)
Fri, 22 Mar 2002 14:57:45 -0800


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/