At Thu, 1 Apr 2021 23:15:42 +0200, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote: Subject: Re: UVM behavior under memory pressure > > Yes, I understand this. But, in an emergency situation like this one (there > is no free ram, swap is full, openscad eventually gets killed), > I would expect the pager to reclaim pages where it can; > like file cache (down to vm.filemin, I agree it shouldn't go down to 0). > > In my case, vm.anonmax is at 80%, and I suspect it was not reached > (I tried to increase it to 90% but this didn't change anything). As I understand things there's no point to increasing any vm.*max value unless it is already way too low and you want more memory to be used for that category and there's not already more use in other categories (i.e. where a competing vm.*max value is too high). It is the vm.*min value for the desired category that isn't high enough to allow that category to claim more pages from the less desired categories. I.e. if vm.anonmin is too low, and I believe the default of 10% is way too low, then when file I/O gets busy for whatever reason, (and with the default rather high vm.filemax value) large processes _will_ get partially paged out as only 10% of their memory will be kept activated. Simultaneously decreasing vm.filemax and increasing vm.anonmin should guarantee more memory can be dedicated to processes needing it as opposed to allowing file caching to take over. I think in general the vm.*max limits (except maybe vm.filemax) are only really interesting on very small memory systems and/or on systems with very specific types of uses which might demand more pages of one category or the other. The default vm.filemax value on the other hand may be too high for systems that don't _constantly_ do a lot of file I/O _and_ access many of the same files more than once. So if you regularly run large processes that don't necessarily do a whole lot of file I/O then you want to reduce vm.filemax, perhaps quite a lot, maybe even to just being barely above vm.filemin; and of course you want to increase vm.anonmin. One early guide suggested (with my comments): vm.execmin=2 # this is too low if your progs are huge code vm.execmax=4 # but this should probably be as much as 20 vm.filemin=0 vm.filemax=1 # too low for compiling, web serving, etc. vm.anonmin=70 vm.anonmax=95 Note that increasing vm.anonmin won't dedicate memory to anon pages if they're not currently needed of course, but it will guarantee at least that much memory will be made available, and kept available, when and if pressure for anon pages increases. So all of these limits are not "hard limits", nor are they dedicated allocations per-se. A given category can use more pages than its max limit, at least until some other category experiences pressure, i.e. until the page daemon is woken. (Just keep in mind that one cannot currently exceed 95% as the sum of the lower (vm.*min) limits. The total of the upper (vm.*max) limits can be more than 100%, but there are caveats to such a state.) Also if you have a really large memory machine and you don't have processes that wander through huge numbers of files, then you might also want to lower vm.bufcache so that it's not wasted. -- 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:
pgpMLdXaFvASa.pgp
Description: OpenPGP Digital Signature