1A random assortment of things that I have thought about from time to time. 2The biggie is: 3 40. Merge the page and buffer caches. 5 This has been bandied about for a long time. First need to decide 6 whether you use VFS routines to do pagein/pageout or VM routines to 7 do IO? Lots of other things to worry about: mismatches in page/FS-block 8 sizes, how to balance their memory needs, how is anon memory represented, 9 how do you get file meta-data, etc. 10 11or more modestly: 12 131. Use the multi-page pager interface to implement clustered pageins. 14 Probably can't be as aggressive (w.r.t. cluster size) as in clustered 15 pageout. Maybe keep some kind of window ala the vfs_cluster routine 16 or maybe always just be conservative. 17 182. vm_object_page_clean() needs work. 19 For one, it uses a worst-case O(N**2) algorithm. Since we might block 20 in the pageout routine, it has to start over again afterward as things 21 may have changed in the meantime. Someone else actively writing pages 22 in the object could keep this routine going forever also. Note that 23 just holding the object lock would be insufficient (even if it was safe) 24 since these locks compile away on non-MP machines (i.e. always). 25 Maybe we need an OBJ_BUSY flag to be check by anyone attempting to 26 insert, modify or delete pages in the object. This routine should also 27 use clustering like vm_pageout to speed things along. 28 293. Do aggressive swapout. 30 Right now the swapper just unwires the u-area allowing a process to be 31 paged into oblivion. We could use vm_map_clean() to force a process out 32 in a hurry though this should probably only be done for "private" objects 33 (i.e. refcount == 1). 34 354. Rethink sharing maps. 36 Right now they are used inconsistently: related (via fork) processes 37 sharing memory have one, unrelated (via mmap) processes don't. Mach 38 eliminated these a while back, I'm not sure what the right thing to do 39 here is. 40 415. Use fictitious pages in vm_fault. 42 Right now a real page is allocated in the top level object to prevent 43 other faults from simultaneously going down the shadow chain. Later, 44 a second real page may be allocated. Current Mach allocates a fictitious 45 page in the top object and replaces it with a real one as necessary. 46 476. Improve the pageout daemon. 48 It suffers from the same problem the old (4.2 vintage?) BSD one did. 49 With large physical memories, cleaned pages may not be freed for a long 50 time. In the meantime, the daemon will continue cleaning more pages in 51 an attempt to free memory. This can lead to bursts of paging activity 52 and erratic levels in the free list. 53 547. Nuke MAP_COPY. 55 It isn't true anyway. You can still get data modified after the virtual 56 copy for pages that aren't present in memory at the time of the copy. 57 The only concern with getting rid of it is that exec uses it for mapping 58 the text of an executable (to deal with the modified text problem). 59 MAP_COPY could probably be fixed but I don't think it is worth it. If 60 you want true copy semantics, use read(). 61 628. Try harder to collapse objects. 63 Can wind up with a lot of wasted swap space in needlessly long shadow 64 chains. The problem is that you cannot collapse an object's backing 65 object if the first object has a pager. Since all our pagers have 66 relatively inexpensive routines to determine if a pager object has a 67 particular page, we could do a better job. Probably don't want to go 68 as far as bringing pages in from the backing object's pager just to move 69 them to the primary object. 70 719. Implement madvise (Sun style). 72 MADV_RANDOM: don't do clustered pageins. (like now!) 73 MADV_SEQUENTIAL: in vm_fault, deactivate cached pages with lower 74 offsets than the desired page. Also only do forward read-ahead. 75 MADV_WILLNEED: vm_fault the range, maybe deactivate to avoid conspicuous 76 consumption. 77 MADV_DONTNEED: clean and free the range. Is this identical to msync 78 with MS_INVALIDATE? 79 8010. Machine dependent hook for virtual memory allocation. 81 When the system gets to chose where something is placed in an address 82 space, it should call a pmap routine to choose a desired location. 83 This is useful for virtually-indexed cache machine where there are magic 84 alignments that can prevent aliasing problems. 85 8611. Allow vnode pager to be the default pager. 87 Mostly interface (how to configure a swap file) and policy (what objects 88 are backed in which files) needed. 89 9012. Keep page/buffer caches coherent. 91 Assuming #0 is not done. Right now, very little is done. The VM does 92 track file size changes (vnode_pager_setsize) so that mapped accesses 93 to truncated files give the correct response (SIGBUS). It also purges 94 unmapped cached objects whenever the corresponding file is changed 95 (vnode_pager_uncache) but it doesn't maintain coherency of mapped objects 96 that are changed via read/write (or visa-versa). Reasonable explicit 97 coherency can be maintained with msync but that is pretty feeble. 98 9913. Properly handle sharing in the presence of wired pages. 100 Right now it is possible to remove wired pages via pmap_page_protect. 101 This has become an issue with the addition of the mlock() call which allows 102 the situation where there are multiple mappings for a phys page and one or 103 more of them are wired. It is then possible that pmap_page_protect() with 104 VM_PROT_NONE will be invoked. Most implementations will go ahead and 105 remove the wired mapping along with all other mappings, violating the 106 assumption of wired-ness and potentially causing a panic later on when 107 an attempt is made to unwire the page and the mapping doesn't exist. 108 A work around of not removing wired mappings in pmap_page_protect is 109 implemented in the hp300 pmap but leads to a condition that may be just 110 as bad, "detached mappings" that exist at the pmap level but are unknown 111 to the higher level VM. 112---- 113Mike Hibler 114University of Utah CSS group 115mike@cs.utah.edu 116