At Thu, 23 Apr 2020 11:56:08 +0100, Sad Clouds <cryintothebluesky%gmail.com@localhost> wrote: Subject: Re: Linux compat and swap > > On Thu, 23 Apr 2020 10:56:15 +0100 > Mike Pumford <mpumford%mudcovered.org.uk@localhost> wrote: > > > If you have both memory intensive and filesystem intensive processes > > running on a NetBSD system the kernel filesystem cache can end up > > evicting programs running in the background that are inactive which > > then take a LONG time to recover. For a system with a reasonable > > amount of memory I found the vm.filemin and vm.filemax needed to be > > tweaked so that filesystem cache was more likely to be tweaked than > > program code. > > Is this correct? I always thought that file cache was opportunistic, > i.e. it will use all free memory, but under no circumstances it should > evict any pages of running programs. The opposite should happen, i.e. > any program using memory should be allowed to steal it from file cache > at any time. > Mike's description is correct. Processes can only take over memory from the file cache if the value for vm.filemin is small enough. That is, after all, what vm.filemin means. Here is the VM section of my sysctl.conf, with notes that help explain some of my rationale: # the rest are VM pager tuning parameters # # Questions: # # Does the pager eventually always free inactive pages # above the vm.*max limits? # # It will depend upon the order of pages on the list(?). It will # free pages until there are enough(?) free pages, in the order they # appear on the list. # # Is this worse for exec and file pages than it is for anon pages? # # # Does it even matter if inactive anon pages are preserved for very # long? # # See also: # # http://web.archive.org/web/20181008110324/http://www.selonen.org/arto/netbsd/vm_tune.html # http://chuck.cranor.org/p/diss.pdf # http://usenix.org/publications/library/proceedings/usenix99/full_papers/cranor/cranor.pdf # N.B.: On a live system make sure to order changes to these values so # that you always lower any values from their default first, and then # raise any that are to be raised above their defaults. This way, the # sum of the minimums will stay within the 95% limit. # the minimum percentage of memory always (made) available for the # file data cache # # The default is 10, which is much too high, even for a large-memory # system... # vm.filemin=5 # the maximum percentage of memory that will be reclaimed from others # for file data cache # # The default is 50, which may be too high for small-memory systems # but may be about right for large-memory systems... # #vm.filemax=25 # the minimum percentage of memory always (made) available for # anonymous pages # # The default is 10, which is way too low... # vm.anonmin=40 # the maximum percentage of memory that will be reclaimed from others # for anonymous pages # # The default is 80, which seems just about right, but then again it's # unlikely that the majority of inactive anonymous pages will ever be # reactivated so maybe this should be lowered? # vm.anonmax=80 # the minimum percentage of memory always (made) available for text pages # # The default is 5, which may be far too low on small-RAM systems... # vm.execmin=20 # the maximum percentage of memory that will be reclaimed from others # for text pages # # The default is 30, which seems way too low, esp. for big programs... # vm.execmax=40 # It may also be useful to set the bufmem high-water limit to a number # which may actually be less than 5% (vm.bufcache / options BUFCACHE) # on large-memory systems (as BUFCACHE cannot be set below 5%). # # note this value is given in bytes. # #vm.bufmem_hiwater= -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgp5Y6XHV_8OA.pgp
Description: OpenPGP Digital Signature