Date: Tue, 7 Aug 2018 21:27:04 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Johnston <markj@freebsd.org> Cc: Mark Millard <marklmi@yahoo.com>, freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180808042704.GB26133@www.zefox.net> In-Reply-To: <20180806155837.GA6277@raichu> References: <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <EC74A5A6-0DF4-48EB-88DA-543FD70FEA07@yahoo.com> <20180806155837.GA6277@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 06, 2018 at 11:58:37AM -0400, Mark Johnston wrote: > > My suspicion, based on the high latency, is that this is a consequence > of r329882, which lowered the period of time that the page daemon will > sleep while waiting for dirty pages to be cleaned. If a certain number > of consecutive wakeups and queue scans occur without making progress, > the OOM killer is triggered. That number is vm.pageout_oom_seq - could > you try increasing it by a factor of 10 and retry your test? > It almost worked. OOMA struck when the buildworld.log file was at 27 MB, compared its normal failure point with this USB/microSD mixed swap setup of around 1.6 MB. So, increasing vm.pageout_oom_seq from 12 to 120 certainly helped, a lot. It does seem slightly odd that the delay on the USB swap partition just before the kill was around 1.2 seconds, far less than worst-case. The log files, console output and some sorted derivatives are at http://www.zefox.net/~fbsd/rpi3/swaptests/r337226M/1gbsdflash_1gbusbflash/ > > If the above suggestion doesn't help, the next thing to try would be to > revert the oom_seq value to the default, apply this patch, and see if > the problem continues to occur. If this doesn't help, please try > applying both measures, i.e., set oom_seq to 120 _and_ apply the patch. > > diff --git a/sys/vm/vm_pagequeue.h b/sys/vm/vm_pagequeue.h > index fb56bdf2fdfc..29a16060253f 100644 > --- a/sys/vm/vm_pagequeue.h > +++ b/sys/vm/vm_pagequeue.h > @@ -74,7 +74,7 @@ struct vm_pagequeue { > } __aligned(CACHE_LINE_SIZE); > > #ifndef VM_BATCHQUEUE_SIZE > -#define VM_BATCHQUEUE_SIZE 7 > +#define VM_BATCHQUEUE_SIZE 1 > #endif > > struct vm_batchqueue { I'll try compiling a new kernel with the batchqueue patch and re-run the experiment. Thanks for all your help! bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180808042704.GB26133>