Date: Sat, 24 Nov 2018 09:40:34 -0800 From: Mark Millard <marklmi@yahoo.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: current@FreeBSD.org, freebsd-arm@FreeBSD.org Subject: Re: maxswzone NOT used correctly and defaults incorrect? Message-ID: <D98D8159-433B-4F80-B0BF-AA24E9798186@yahoo.com> In-Reply-To: <20181124104032.GV2378@kib.kiev.ua> References: <20181124090429.GI10067@funkthat.com> <20181124104032.GV2378@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Nov-24, at 02:40, Konstantin Belousov <kostikbel at gmail.com> wrote: > On Sat, Nov 24, 2018 at 01:04:29AM -0800, John-Mark Gurney wrote: >> . . . > OOM is guided by the pagedaemon progress, not by the swap amount left. It would help if the "was killed: out of swap space" messages did not incorrectly point to being out of swap space as the issue. > If the system cannot meet the pagedaemon targetp by doing > $(sysctl vm.pageout_oom_seq) back-to-back page daemon passes, > it declares OOM condition. E.g. if you have very active process which > keeps a lot of active memory by referencing the pages, and simultenously > a slow or stuck swap device, then you get into this state. > > Just by looking at the top stats, you have a single page in the inactive > queue, which means that pagedaemon desperately frees clean pages and > moves dirty pages into the laundry. Also, you have relatively large > laundry queue, which supports the theory about slow swap. > > You may try to increase vm.pageout_oom_seq to move OOM trigger furhter > after the system is overloaded with swapping. > >> . . . > The swap metadata zones must have all the KVA reserved in advance, > because we cannot wait for AS or memory while we try to free some > memory. At boot, the swap init code allocates KVA starting with the > requested amount. If the allocation fails, it reduces the amount by > 2/3 and retries, until the allocation succeeds. What you see in limits > is the actual amount of KVA that your platform is able to provide for > reserve, so increasing the maxswzone only results in more iterations to > allocate. The documentation's "corresponds to eight times the amount of physical memory" text again seems not helpful unless it happens to be about the figure for the actual context. Could something like your wording above be put in place instead? An example: armv7 rpi2's and aarch64 rpi3's, both with 1GiByte of RAM, get very different figures for the "exceeds maximum recommended amount" figure, different by very roughly a factor of 2 if I remember right, neither near what the documentation suggests. Suggesting a fixed ratio to RAM-size just seems to be wrong. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D98D8159-433B-4F80-B0BF-AA24E9798186>