[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

memory_object_lock_request and memory_object_data_return fnord

From: Neal H Walfield
Subject: memory_object_lock_request and memory_object_data_return fnord
Date: 13 Mar 2002 20:27:03 -0500
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1

If a memory manager issues a memory_object_lock_request to gain
read/write access to a set of pages (i.e. evoking all of the kernel's
access rights), the kernel will eventually return any modified pages
in the range using the memory_object_data_return message and end the
sequence with a memory_object_lock_completed message.  This is similar
to normal eviction path.

In the latter case, the page is returned to the memory manager with
the expectation that it will immediately be written to the backing
store and freed.  The kernel cannot, however, be sure.  As such, it
changes the association of the page from the manager to the trusted
default pager.  This way, if the manager fails to free the page in a
timely fashion, the kernel can still flush it to swap.

Yet, what happens in the former case?  Specifically, how will the
returned pages be evicted?  Will the kernel send another
memory_object_data_return?  Unlikely.  It has nothing to return.  So,
the page will be evicted via the default pager.  What is the correct
way to give the management of the page back to the kernel?  Perhaps,
we could use the memory_object_data_supply message (and if we modified
it, we could supply it as precious).  _The Mach 3 Kernel Interfaces_
cautions against supplying data that has not been explicitly request,
however, it does not prohibit it.  And yet, what if milliseconds from
now we get another message to write to the page?  Again, we need to go
through the same song and dance -- request the page, write to it and
return it to the kernel.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]