On Wed, Aug 22, 2007 at 03:05:15PM +0800, Wee Yeh Tan wrote: > On 8/22/07, Peter C. Norton <[EMAIL PROTECTED]> wrote: > > The swap to zpool idea is very interesting. But this brings up another > > question in the puzzle for us... What is this mythical creature, a > > page size, in the Solaris VM, when it comes to tuning? You have > > Here's Richard McDougall's excellent blueprint about this topic. > <http://www.sun.com/blueprints/0304/817-5917.pdf> > > The paper investigates the impact on TLB but did not discuss (IIRC) > the impact on swap. > > > variable pages in solaris, but in practice you can only get a single > > large page on x86 (sparc seems to be better) which indicates a > > horrendous amount of fragmentation in the VM, never myind how that is > > reflected in swap, enough that you just can't get large page > > performance. > > I am not sure I understand you correctly. Why will a single large > page (I suppose you mean 2MB) on x86 indicate fragmentation?
Because if you try to get more than one page there does not appear to be another 2MB of contiguous space available, ever. You cannot get a second 2MB page. Ever. Never. It is fragmentation because it indicates that you can't get pages arranged so that you can have 4MB contiguous in a 16gb system. > > In any case, are you optimizing for 2k or 2M pages? Does it make a > > difference? I suspect it skews some of the considerations, but I'm not > > sure exactly how. > > Depending on application, larger pages are not always good or bad. > Since the topic is about swap, large pages should suck for swap. The > entire page needs to be brought back to memory so, depending on > application again, smaller pages may be more efficient. On the other > hand, the entire 2MB will most likely be swapped out contiguously so > reading back the full 2MB can be slightly fast. It seems like in the situation of >100mb being swapped out large pages would be a big win, but we haven't been able to find out since we have only managed to get a single large page. -Peter -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
