Re: explanation of page in and page cache hit
Re: explanation of page in and page cache hit
- Subject: Re: explanation of page in and page cache hit
- From: Dan Shoop <email@hidden>
- Date: Thu, 10 Dec 2009 23:06:08 -0500
On Dec 10, 2009, at 6:03 PM, Shawn Erickson wrote:
> On Thu, Dec 10, 2009 at 1:08 PM, Joel Reymont <email@hidden> wrote:
>> ---
>> Page In: A nonresident page was read from disk.
Generally you should say it's read from "backing store", since a page could come from the application binary (there's no program loader), swap, shared memory, data that is backed by a file, or be a special page type. (And "file" has a very loose term in unix parlance.) Demand-Zero pages would be a special page type and would not be read from disk either. Swap may also not be "disk." Likewise the page could be faulted in from an encrypted data store (perhaps in memory), or through a user-space pager and who knows where that means it could come from.
Therefore a page could certainly be paged into the working set of a process' virtual address space but *not* be read from disk making that definition very poor. For example, a shared or a COW page. It's already in memory so it wouldn't be faulted from disk and would only get instantiated separately when it was written to by the process.
>> Page Cache Hit: A resident, but unmapped page was touched.
Use of the word "unmapped" here is rather fuzzy. What does the OP mean by this?
I suspect he means that it's not physically mapped, that is it's not pmap'ed, but this is different than being mapped as an entry in the process' virtual address space. This may or may not be part of its working set and the page may or may not also be considered "cached" if it was COW or demand-zero, depending on your definitions.
A page could be retrieved from cache if it had previously been unmapped and was mapped back in and requested, or if it had faulted out of the active working set due to active page quotas (but would still be mapped) and was cached on the inactive list. If it was physically faulted out and requested it could be either swapped back (in the case it was modified) or re-read directly from its original backing store (it wasn't swapped.)
>>
>>
>> Does a page become resident but unmapped after a page-in?
>
> Don't think so (if I understand what you are asking). A page-in makes
> it both resident and mapped for the requesting process.
Again, depending on exactly what the OP means here, the page would certainly be mapped, otherwise it could not generate a fault. A page would have to exist as part of the process virtual address space in order to be referenced. A page in the virtual address space would be mapped but may or may not be resident and may or may not yet have been referenced so it may or may not be resident in physical memory.
>
>> What is a resident, but unmapped page?
>
> IIRC the need page exists in physical memory already but it isn't
> currently mapped into the requesting process.
Again this comes down to what the OP means by "unmapped".
A shared page may be resident in memory but not in the current process' virtual address space yet. It would be resident but not mapped.
A page that would be unmapped could be one that the process "threw away" or de-referenced, that is it's not part of the processes virtual address space. That page could then be on the inactive list and if it was shared or COW and never written, it could be resident and no longer be mapped by the process.
Likewise all shared and active pages are resident but would only be mapped when the process added it to its virtual address space. (For instance it references a shared library that's dynamically loaded.)
You may want to pick up a book on Operating Systems, I normally point people to Deitel's book which has a fairly readable Virtual Memory section, however I defer even my own comments here to Sigh's "Mac OS X Internals" for Mac OS X functionality and any Mac specific parlance.
-d
------------------------------------------------------------------------
Dan Shoop
Computer Scientist
email@hidden
GoogleVoice: 1-646-402-5293
aim: iWiring
twitter: @colonelmode
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden