:I am creating a virtual memory manager.
:
:Currently I am doing a
:mmap(...PROT_NONE, MAP_ANON ) to reserve the memory.
:then when committing the memory I am using mprotect( ...PROT_READ |
:PROT_WRITE )
:
:HTH
:
:Jason Mawdsley ~ [EMAIL PROTECTED]
:m_ a c a d a m i a n t e c h n o l o g i e s
:
:"Software developers for the world's leading technology companies."
:http://www.macadamian.com
Hmm. Well, the memory is already virtual. mprotect() can be
used to force a SIGBUS if the process tries to access the
protected memory in a manner you do not allow, but it will
have no effect on how FreeBSD manages the memory on the backend.
mmap() w/ MAP_ANON will reserve memory but not allocate it
until you access it (read or write), on a page by page basis.
munmap() will free memory immediately and cause any further
references to the unmapped address space in question to generate
a SIGSEGV signal. However, it is not recommend that you use
munmap() to manage freeing memory on a page-by-page basis due
to its overhead. If you don't need a hard signal on access failures
then madvise(...MADV_FREE...) is the better way.
mprotect() can be used to prevent reading and/or reading &
writing to the address space in question without destroying
any of the data (i.e. you can mprotect() a piece of memory
so it is not accessible, and then mprotect() again later
to make it accessible with the original contents undisturbed).
Accesses to mprotect()ed memory in a manner not allowed by
the mprotect() will result in a SIGBUS signal.
mprotect() has rather serious overhead. If you don't need
to handle hard-signals on access failures you should use
madvise(...MADV_FREE) to 'free' (uncommit) memory.
madvise() can be used in a number of ways, but the most common
way is to use MADV_WILLNEED and MADV_FREE. MADV_WILLNEED does
*NOT* commit or reserve physical memory in any way, it simply
advises FreeBSD that you will need the memory soon and FreeBSD
will try to make sure (but will not guarentee) that any swapped-out
pages are swapped in. MADV_FREE is a soft version of munmap() -
it 'decommits' the memory, allowing FreeBSD to throw it away at any
time until the next access (on a page-by-page basis), but it doesn't
do it instantly like mmap(). Instead the memory is only thrown away
if FreeBSD hits a memory shortage, and the memory is left
mapped so you can simply access it (read or write) to re-commit
the memory (but when you do so you are not guarenteed that the
contents as of the time of the MADV_FREE were kept intact,
only that whatever contents is there remains intact after you
access it again).
msync() has no effect on anonymous (MAP_ANON) memory. It only
effects file-backed memory.
Committing physical or swap space to back anonymous memory
(you don't have any control over which FreeBSD uses) is
simple: You simply access (read or write) the memory in
question (this occurs on a page-by-page basis).
Generally speaking you have very little control over when
FreeBSD pages allocated memory in and out of swap, and
generally you shouldn't have to worry about it because FreeBSD
does a very good job figuring out what it should and should
not page out.
mincore() can be used to determine whether pages of virtual
memory are actually assigned physical pages or whether they
have been paged out to swap.
mlock() and munlock() can be used to lock virtual memory into
physical store, but only root can call these functions and they
are considered to be rather dangerous.
FreeBSD's manual pages are fairly complete in describing what these
functions do, you should look at them:
http://www.FreeBSD.org/cgi/man.cgi?manpath=FreeBSD+4.4-stable
e.g. type in 'madvise' and submit.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
