:which one does the data come from?
:
:On Thu, 7 Mar 2002, Zhihui Zhang wrote:
:
:>
:> Is there any fundamental reason why a page can not be owned by more than
:> one VM object? If that was the case, the bogus page stuff in vfs_bio.c
:> could be made cleaner IMHO.
:>
:> -Zhihui
:>
I think there is some confusion here. The bogus_page stuff in vfs_bio
has nothing to do with VM page ownership. Bogus_page's are used when
a BIO buffer is reconstituted from pages in the VM Page cache. In
this situation some pages required to reconstitute the buffer may be
missing and other pages may be dirty. In order to deal with this case
new pages must be allocated for the ones that are missing and a bogus
page must be mapped into the BIO buffer for the page that is dirty in
order for the BIO system to be able to issue a 'read' to fill in the
missing data and not accidently overwrite the dirty page. When the
I/O is complete, the bogus page is removed and the original dirty
page takes its place. This occurs entirely within the domain of BIO.
bogus pages have nothing to do with real VM pages and VM objects.
VM object ownership of a page is totally independant from memory mappings
of the page. A VM page can only be associated with a single VM object,
but it can be mapped into memory in many places and by many processes.
For example, you can mmap() offset 4096 in a file at location X, and you
can mmap() the SAME offset at location Y, so you wind up with two
different VM addresses associated with the same page. It is the
job of the PMAP subsystem to keep track of these (hardware MMU / pagetable)
mappings. In the same manner, pages may be wired into kernel virtual
memory (KVM), which is how the buffer cache works. But the page is
still 'owned' by a single VM object.
I recommend reviewing vm/vm_mmap.c and vm/vm_map.c .. specifically,
the vm_map_entry structure (which maps VM objects into an address
space), and i386/i386/pmap.c (which tracks MMU mappings), and
vm/vm_pageout.c and vm/vm_object.c (so you can see how object
flushing works.. I suggest reading the vm_object_page_clean()
procedure).
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
