> > but there's too much code out there that just breaks. The >> programmers made implicit assumptions about the approximate >> size of a page, and that was that. > > Which code breaks ? Userland or kernel code ? Was
Userland. The problem is that mmap() exposed too much detail and as a result assumptions about sysconf(_SC_PAGESIZE) or even the range of possible values resulted in programs dying when sysconf returns 64K for the pagesize. In other words, the value of sysconf(_SC_PAGESIZE) has sort of defacto ended up baked into the Solaris ABI in an unintentional way. To make matters worse, Solaris (unlike many other OS's) ties page_t structures to particular physical addresses, and there is plenty of code that assumes p_pagenum can't change even if the page isn't locked. This complicates the issues of separating out the "page size" the user sees and the "page size" the kernel is using to manage physical memory. The whole notion of changing the system page size to improve performance, etc. is sort of the wrong way to go about this anyway. Fundamentally, the issues around performance in Solaris virtual memory are a result of the system using O(npages) algorithms. Increasing the page size by a factor of 8 doesn't help much when memories are growing at a 1.5x year-over-year. The TLB issues (which it appears spurred this discussion) can be dealt with in other ways, and already are to some degree by automating MPSS use of large pages -- support that is there today, and improving over time. Moving forward the goal is to start managing memory more in O(nsegs) rather than O(npages) since programs tend to be bifurcated -- most segments are either a few KB or a few MB, and a handful of big apps have segments which take up a good percentage of the machine's physical memory. Handling memory as a resource like a disk, instead of a collection of pages, will speed up things like fork(), reduce the overhead of faults (if not eliminate them) and leave plenty of freedom for the underlying platform code to optimize for whatever TLB the chip happens to have by keeping memory mostly physically contiguous. - Eric This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
