On 3/9/06, Eric Lowe <[EMAIL PROTECTED]> wrote: > >> The performance > >> analysis was, as I recall, done mostly using US-III+. > > > > Did this include the concept that dwarfpages (8k) are no longer > > available to both kernel and user land applications? > > I wasn't directly involved in the 64K prototype but only 64K and larger > were used for user applications, and the page_t was 64K in span > (PAGESIZE=65536). There may have been some 8K mappings in the kernel due > to OBP handing off translation lists with holes -- I don't remember the > details there.
Who was involved in this project? > > Can Sun release the code? I'd be more than happy to write a project > > proposal then. I assume we will receive some help from the HPC > > community. The next generation of vector supercomputers may use > > similar large page sizes (>= 64k) as minimum configurable value and > > Opensolaris may be a good testbed implementation - assuming we can > > completely eradicate dwarfpages from kernel and user land. > > I'll ask around. Did you receive any answers yet? I'd like to write a project proposal for a 64k kernel project - assuming Sun is willing to release the sources of their original prototype. > Keep in mind though that just flipping page_t's to be 64K isn't a magic > pill; most applications in the HPC space, etc. still need huge pages to > fit their working set in the TLB, and spend most or all of their TLB > misses on the working data set, so 64K is not likely to be a win at all in > that space. It depends on the application. For the majority of smaller and medium sized applications such as FEM 64k pages have a serious advantage. I/O operations are limited by dwarfpages, too. MPSS buys nothing in this case. -- Holger
_______________________________________________ opensolaris-discuss mailing list [email protected]
