Rik, I think Mike deserves his beer. ;)
Agreed. Swap reclaim doesn't seem to be the root issue here, IMHO.
But instead: his box was capable of maintaining a modest cache
and the desired user processes without massive allocations (and use)
of swap space. There was plenty of cache to reap, but VM decided to
swapout instead. Seems we're out of balance here (IMHO).
I see this too, and it's only a symptom of post-2.4.4 kernels.
Example: on a 128M system w/2.4.5, loading X and a simulation code of
RSS=70M causes the system to drop 40-50M into swap...with 100M of cache
sitting there, and some of those cache pages are fairly old. It's not
just allocation; there is noticable disk activity associated with paging
that causes a lag in interactivity. In 2.4.4, there is no swap activity
at all.
And if the application causes heavy I/O *and* memory load (think
StarOffice, or Quake 3), this situation gets even worse (because there's
typically more competition/demand for cache pages).
And on low-memory systems (ex. 32M), even a basic Web browsing test w/
Opera drops the 2.4.5 system 25M into swap where 2.4.4 barely cracks 5 MB
on the same test (and the interactivity shows). This is all independent
of swap reclaim.
So is there an ideal VM balance for everyone? I have found that low-RAM
systems seem to benefit from being on the "cache-collapse" side of the
curve (so I prefer the pre-2.4.5 balance more than Mike probably does) and
those low-RAM systems are the first hit when, as now, we're favoring
"cache bloat". Should balance behaviors could be altered by the user
(via sysctl's maybe? Yeah, I hear the cringes)? Or better, is it
possible to dynamically choose where the watermarks in balancing should
lie, and alter them automatically? 2.5 stuff there, no doubt. Balancing
seems so *fragile* (to me).
Cheers,
Craig Kulesa
ckulesa@as.arizona.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/