Re: A question of VM page ownership
* Zhihui Zhang <[EMAIL PROTECTED]> [020307 08:28] 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. There is only enough linkage in the vm page to support it being associated with one object. see src/sys/vm/vm_page.h -Alfred Perlstein [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A question of VM page ownership
The mapping between data objects (one-to-one or one-to-many) seem to be
the most troublesome stuff to deal with when introducing new data
structures. But if there is never the need to lookup an object from a
page, then maybe we can use a linkage structure like this:
struct vm_page_linkage {
TAILQ_ENTRY(vm_page_linkage) pageq;
struct vm_page * page;
}
-Zhihui
On Thu, 7 Mar 2002, Alfred Perlstein wrote:
> * Zhihui Zhang <[EMAIL PROTECTED]> [020307 08:28] 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.
>
> There is only enough linkage in the vm page to support it being associated
> with one object. see src/sys/vm/vm_page.h
>
> -Alfred Perlstein [[EMAIL PROTECTED]]
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: A question of VM page ownership
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. When you need to reclaim the page, you would have to identify all owners, rather than a single owner. THis converts the lookup fron an O(1) to an O(N) problem. Keeping a linked list of owners doesn't really help, either, since it introduces locking issues that will cause -current to blow chunks. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A question of VM page ownership
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 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A question of VM page ownership
The bogus page is owned by the system object, not by individual objects associated with the files. If a page could be owned by more than one objects, then we could let the object associated with a file to own the bogus page. -Zhihui On Thu, 7 Mar 2002, Julian Elischer wrote: > 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 > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A question of VM page ownership
: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
