lkml.org 
[lkml]   [2002]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.081 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site