On Fri, Mar 24, 2006 at 12:28:05AM +0100, Roland Mainz wrote: > Eric Lowe wrote: > > David S. Miller wrote: > > > Or did Solaris accidently return 8K always in some version of the > > > Solaris libc? I don't see how this is possible, as applications > > > > No that wasn't the case. The case Bart mentioned was one, an app was > > creating a unmapped zone around a segment and the segment ended up all > > being unmapped because they were subtracting 64K off of each end of a 128K > > segment. It was clearly a bug but since the app was statically linked to > > library code containing the bug there wasn't a good way to fix it in the > > field. > > AFAIK such applications (with statically linked system libraries) are > not supported on Solaris since a while so we do not have this problem > anymore. Neither does this affect binary backwards-compatibility for the > same reason. Next problem, please... :-)
It wasn't a *system* library that was statically linked against. > > There were the other drawbacks I mentioned as well, which we could get > > around by only upping the pagesize on newer platforms with better cache > > associativity and larger memory. This approach may be tenable. > > IMO such a project will have serious benefits and I am wondering why Sun > simply dropped it that fast (are there any other issues which caused the > death of the project ?). The amount of complexity to support "pseudo" 8k user pages was hard to swallow. The backwards compatibility concerns were real; if one program was broken, then there's a strong possibility that other programs are broken in the same way. I believe there was also some amount of filesystem muckings-around; the fact that the minimum unit of modification octupled causes any number of performance and implementation headaches. Let alone assumptions about filesystem blocksize and PAGESIZE being close to each other. Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
