Message-ID: <3C9BB6E9.16D1C533@zip.com.au>
Date: Fri, 22 Mar 2002 14:57:45 -0800
From: Andrew Morton <akpm@zip.com.au>
MIME-Version: 1.0
To: Tony.P.Lee@nokia.com
CC: linux-kernel@vger.kernel.org
Subject: Re: mprotect() api overhead.
In-Reply-To: <4D7B558499107545BB45044C63822DDE3A2043@mvebe001.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

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/