We want it to swap less for this particular operation because it is lowpriority compared to the rest of what's going on inside the box.

We've considered both artificially manipulating swap on the fly similar toyour suggestion as well a parallel thread that pumps a 3 into drop_cachesevery few seconds while the update is running, but these seem too much likehacks for our liking. Mind you, if we don't have a choice we'll do what weneed to get the job done but there's a nagging voice in our conscience thatsays keep looking for a more elegant solution and work *with* the kernelrather than working against it or trying to trick it into doing what wewant.

We've already disabled OOM so we can at least keep our testing alive whilesearching for a more elegant solution. Although we want to avoid swap inthis particular instance for this particular reason, in our hearts we agreewith Andrew that swap can be your friend and get you out of a jam once in awhile. Even more, we'd like to leave OOM active if we can because we want tobe told when somebody's not being a good memory citizen.

Some background, what we've done is carve up a huge chunk of memory that isshared between three resident processes as write cache for a proprietaryblock system layout that is part of a scalable storage architecturecurrently capable of RAID 0, 1, 5 (soon 6) virtualized across multiplechassis's, essentially treating each machine as a "disk" and providingmultipath I/O to multiple iSCSI targets as part of a grid/array storagesolution. Whew! We also have a version that leverages a battery backed writecache for higher performance at an additional cost. This software isinstallable on any commodity platform with 4-N disks supported by Linux,I've even put it on an Optiplex with 4 simulated disks. Yawn ... yet anotheriSCSI storage solution, but this one scales linearly in capacity as well asperformance. As such, we have no user level apps on the boxes and preciouslittle disk to spare for additional swap so our version of the swapmanipulation solution is to turn swap completely off for the duration of theupdate.

I hope I haven't muddied things up even more but basically what we want todo is find a way to limit the number of cached pages for disk I/O on the OSfilesystem, even if it drastically slows down the untar and verify processbecause the disk I/O we really care about is not on any of the OSpartitions.

> during tar extraction ... inactive pages reaches levels as high as ~375000

So why do you want the system to swap _less_? You need to find some free memory for the additional processes to run in, and you have lots of inactive pages, so I think you want to swap out _more_ pages.

I'd suggest to temporarily add a swapfile before you update your system. This can even help in bringing your memory use to the state before if you do it like this - swapon additional swapfile - update your database software - swapoff swap partition - swapon swap partition - swapoff additional swapfile