Date: Tue, 20 Apr 1999 12:28:26 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Dyson <dyson@iquest.net> Cc: hackers@FreeBSD.ORG Subject: Re: Directories not VMIO cached at all! Message-ID: <199904201928.MAA99383@apollo.backplane.com> References: <199904192039.PAA20464@dyson.iquest.net> <199904192051.NAA90282@apollo.backplane.com> <371CCB06.2DDECFA@iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:Because I am under alot of pressure right now, all of my responses
:to Matt's concerns follow. Note that it seems that he and I are
:arguing about expediency vs. solution. I prefer solution, and more
:work is necessary (a quick-fix isn't a solution.)
All right. Then what about this.... right now vm_page_t's are
required to be PAGE_SIZE'd.
We change this. We allow vm_page_t's to be sized in multiples of
DEV_BSIZE from 0 through to PAGE_SIZE, but not crossing a physical
page boundry. We get rid of vm_page_t->valid and vm_page_t->dirty and
turn those into PG_VALID and PG_DIRTY flags. we add vm_page_t->size.
When the VM systems goes to lookup a page, the caller requests the
page size. If pgsize is 0, any page size is allowed to be returned.
vm_page_lookup(object, pindex)
becomes
vm_page_lookup(object, pindex, pgsize)
Any portion of the VM system which needs PAGE_SIZE'd VM pages specifically
requests the page with pgsize == PAGE_SIZE, resulting in NULL if the page
does not exist or if it is the wrong size which then forces an I/O ( the
I/O routines would be responsible for 'resizing' an underlying page ).
If non-NULL is returned when a PAGE_SIZE page is requested, the vm_page_t
is perfectly suitable for being sent through the pmap() routines.
Otherwise it is not. The portions of the VM system that need the page
to be PAGE_SIZEd, such as vm_fault, require it and then continue to operate
as they currently do. The portions of the VM system that do not specify
pgsize == 0 and deal with the result.
So:
* get rid of valid
* get rid of dirty
* add PG_VALID, PG_DIRTY
* add 'short size'
* the 'parent' VM page is inherent based on the physical address of
the page found in phys_addr. when a sub-page-sized page is allocated,
the associated parent is disassociated from the page queues and held.
And:
* Require pgsize argument to vm_page_lookup()
* Implement secondary static or dynamic vm_page_t array
* Remove buffer cache valid/dirty bitmask code
* Add buffer cache sized vm_page handling code
* Remove buffer cache B_MALLOC junk entirely
* Consolidate and clean up buffer cache code
The BUFFER CACHE then says 'ok, we do *not* need PAGE_SIZE'd VM pages'.
Buffer cache problem solved. Not only that, but the buffer cache is
greatly simplified because it does not have to scan the valid/dirty bits.
The core vm_page array stays as it currently is and is only used for
PAGE_SIZE chunks. A secondary 'dynamic' vm_page array is used to allocate
sub-page-sized vm_page_t's. When a sub-page-sized vm_page_t is allocated,
it may have to reserve a full but unassociated vm_page_t 'parent' as
backing for it. However, when multiple sub-page-sized chunks are
allocated, the same parent can be used as long as there is space.
We would also be able to use this to extend support for segment sized
pages.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904201928.MAA99383>