RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"]

bob prohaska fbsd at www.zefox.net
Wed Aug 8 04:26:50 UTC 2018


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









More information about the freebsd-arm mailing list