Remembering that Linux doesn't "swap" in the classic sense, but demand pages (the name is an unfortunate carry forward from a time when things were different). Swappiness is merely an indication to page replacement of how you would like pages "biased" when the time comes to toss some out - 100 says keep the page/file cache in storage as much as possible, 0 (zero) says swap (anybody) only as a last resort. Move the "slider" to a number anywhere in-between that feels comfortable. This is an indication of preference only - in a stress situation your input will be ignored. Well it should be - I have trouble explaining what Marcy saw at the setting of 60.
It's a pretty "rubbery" control. Personally I'd have to think a low(-ish) number would be preferable on a production server in this environment - especially if you took the advice to arrange the Linux memory to allow (force) z/VM to handle the paging. When I tested drop_caches (when it was first released into the mainline) I thought it was terrific - especially to ameliorate the effects of things like updatedb running at 03:00 every day. Biggest benefit I found was in the reclaim of space lost to (presumably) fragmented slabs. With the release of the SLUB allocator, and the subsequent updates to it and the slab allocator, this may not be such an issue on recent kernels. I don't think I'd want to be running it regularly in a production server. Caveat - all my testing was done on non-s390 kit. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
