/* * generic VM putpages routine. * Write the given range of pages to backing store. * * => "offhi == 0" means flush all pages at or after "offlo". * => object should be locked by caller. we return with the * object unlocked. * => if PGO_CLEANIT or PGO_SYNCIO is set, we may block (due to I/O). * thus, a caller might want to unlock higher level resources * (e.g. vm_map) before calling flush. * => if neither PGO_CLEANIT nor PGO_SYNCIO is set, we will not block * => if PGO_ALLPAGES is set, then all pages in the object will be processed. * => NOTE: we rely on the fact that the object's memq is a TAILQ and * that new pages are inserted on the tail end of the list. thus, * we can make a complete pass through the object in one go by starting * at the head and working towards the tail (new pages are put in * front of us). * => NOTE: we are allowed to lock the page queues, so the caller * must not be holding the page queue lock. * * note on "cleaning" object and PG_BUSY pages: * this routine is holding the lock on the object. the only time * that it can run into a PG_BUSY page that it does not own is if * some other process has started I/O on the page (e.g. either * a pagein, or a pageout). if the PG_BUSY page is being paged * in, then it can not be dirty (!PG_CLEAN) because no one has * had a chance to modify it yet. if the PG_BUSY page is being * paged out then it means that someone else has already started * cleaning the page for us (how nice!). in this case, if we * have syncio specified, then after we make our pass through the * object we need to wait for the other PG_BUSY pages to clear * off (i.e. we need to do an iosync). also note that once a * page is PG_BUSY it must stay in its object until it is un-busyed. * * note on page traversal: * we can traverse the pages in an object either by going down the * linked list in "uobj->memq", or we can go over the address range * by page doing hash table lookups for each address. depending * on how many pages are in the object it may be cheaper to do one * or the other. we set "by_list" to true if we are using memq. * if the cost of a hash lookup was equal to the cost of the list * traversal we could compare the number of pages in the start->stop * range to the total number of pages in the object. however, it * seems that a hash table lookup is more expensive than the linked * list traversal, so we multiply the number of pages in the * range by an estimate of the relatively higher cost of the hash lookup. */