tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: UVM behavior under memory pressure

At Thu, 1 Apr 2021 23:15:42 +0200, Manuel Bouyer <> 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

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

	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.filemax=1	# too low for compiling, web serving, etc.

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 <>

Kelowna, BC     +1 250 762-7675           RoboHack <>
Planix, Inc. <>     Avoncote Farms <>

Attachment: pgpMLdXaFvASa.pgp
Description: OpenPGP Digital Signature

Home | Main Index | Thread Index | Old Index