[lkml]   [2002]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectmprotect() api overhead.

We like to design a software in certain module way. For example,
a for infiniband switch manager
might manager 128 MBytes of share memory data. 10 or more
applications will call the APIs in the
to get/set the forward table data.

Since the data manager by this share library are globally share,
there is a chance that someone might corrupt this data via
invalid pointers. Or even if we don't give them a pointer, the
application can still corrupt the share memory with an uninitialized
pointer on it stack. This type of problem are extremely hard
to debug.

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 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 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.

For x86 system, is there way to specify 4MB page table entry
instead of 4K page table entry when use the mmap() api.
With 4MB mmap() page table entry, mprotected should take only
8 iterations to change the access bits for 32 MB of share
memory as compare to 8k iterations for 4k page table entries.
Am I corrected on this?


Tony Lee Nokia Networks, Inc.
Work:(650)864-6565 545 Whisman Drive - Bld C
Mountain View, CA 94043

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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