Lei, I have some quick answers for you below:
On Tue, 2006-09-26 at 12:28, Lei Jin wrote: > Two questions: > > 1. What page fault happens, how does opensolaris pick the page frame to > establish the mapping? I mean which physical frame will be picked? What is > the algorithm here? Is the algorithm like page coloring implemented? > We do page coloring to get the color for the given page. The number of colors is loosely based upon the number of pages that can fit in the L2 cache. Check out the code at: http://cvs.opensolaris.org/source/xref/on/usr/src/uts/sun4/vm/vm_dep.h#340 334 /* 335 * AS_2_BIN macro controls the page coloring policy. 336 * 0 (default) uses various vaddr bits 337 * 1 virtual=paddr 338 * 2 bin hopping 339 */ 340 #define AS_2_BIN(as, seg, vp, addr, bin) ... > 2. How does the opensolaris maintain the free page list? > This largely depends upon the system type, but there are a few different levels. http://cvs.opensolaris.org/source/xref/on/usr/src/uts/sun4/vm/vm_dep.c#903 899 /* 900 * Per page size free lists. 3rd (max_mem_nodes) and 4th (page coloring bins) 901 * dimensions are allocated dynamically. 902 */ 903 page_t ***page_freelists[MMU_PAGE_SIZES][MAX_MEM_TYPES]; and as you'll see in the use of page_freelists: http://cvs.opensolaris.org/source/xref/on/usr/src/uts/sun4/vm/vm_dep.h#84 84 #define PAGE_FREELISTS(mnode, szc, color, mtype) \ 85 (*(page_freelists[szc][mtype][mnode] + (color))) 86 87 #define PAGE_CACHELISTS(mnode, color, mtype) \ 88 (*(page_cachelists[mtype][mnode] + (color))) referencing into the freelists include parameters of: mnode - an mnode represents a logical group of memory that has the same latency. Thus on a large system which has multiple boards, with each board containing memory, each board can be it's own mnode. szc - The size code for the page sparc : 8K, 64K, 512K, 4M, 32M, 356M and x86 : 4K, 2M (non-pae mode) and I think 4K and 4M in pae mode (not an x86 expert here :) color - the page color that we want to allocage mtype - the type of page. For sparc, this is either relocatable or non-relocatable. The cachelists only contain base page sizes and thus there is no szc dimension. Pages on the cachelist have an identity and represent pages which can quickly be mapped back in. Some filesystems use the cachelist as their primary cache. Check out http://blogs.sun.com/mec where there is some more information about how we go about allocating large pages, and make sure to check out the comments in vm_dep.h to hopefully get a better understanding for how the freelists are organized. Hope this helps, Mike > Any information will be helpful. Thanks! > > Lei > > > This message posted from opensolaris.org > _______________________________________________ > opensolaris-code mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/opensolaris-code _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
