Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 Jul 2018 20:45:11 -0700
From:      bob prohaska <fbsd@www.zefox.net>
To:        Mark Millard <marklmi@yahoo.com>
Cc:        "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>, freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net>
Subject:   Re: RPI3 swap experiments
Message-ID:  <20180801034511.GA96616@www.zefox.net>
In-Reply-To: <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com>
References:  <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 31, 2018 at 07:09:43PM -0700, Mark Millard wrote:
> 
> 
> On 2018-Jul-31, at 4:19 PM, bob prohaska <fbsd AT www.zefox.net> wrote:
> 
> > On Tue, Jul 31, 2018 at 01:49:57PM -0700, Mark Millard wrote:
> >> On 2018-Jul-31, at 12:10 PM, bob prohaska <fbsd at www.zefox.net> wrote:
> >> 
> >> 
> >>> Some weeks (months?) ago there was a thread about swap being broken. Was
> >>> that in any way related to what I'm seeing?
> >> 
> >> There was some ZFS context stuff that seemed to be independent of
> >> UFS stuff relative to memory use. I continue to see reports tied
> >> to ZFS contexts.
> >> 
> >> But I'm not sure if this is in any way related to what you are
> >> calling "swap being broken". I do not remember anything about
> >> swap being directly broken for swap partitions. (Swap files are
> >> a different issue and are problematical.)
> >> 
> > 
> > The thread I'm referring to starts with 
> > https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069728.html and titled
> > " swapping is completely broken in -CURRENT r334649? "
> > 
> > There's no mention whether ARM is affected, just "certain hardware". 
> > It looks like a bug was introduced in r329882 and fixed in r334752.
> > Workarounds suggested  include 
> > sysctl vm.pageout_update_period=0
> > and
> > sysctl vm.pageout_update_period=1000. 
> > 
> > Maybe the first will turn OOMA off, and the second delay it? 
> > On  RPi the value is 600. The one correspondent who tried 1000
> > said it didn't help, maybe zero is a better guess. For me it's
> > a shot in total darkness either way 8-) 
> 
> In that thread is the message:
> 
> https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069835.html
> 
> that has a patch for dumping out more information to demsg before
> it does the kill:
> 
> diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c
> index 264c98203c51..9c7ebcf451ec 100644
> --- a/sys/vm/vm_pageout.c
> +++ b/sys/vm/vm_pageout.c
> @@ -1670,6 +1670,8 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, int page_shortage,
>  	 * start OOM.  Initiate the selection and signaling of the
>  	 * victim.
>  	 */
> +	printf("v_free_count: %u, v_inactive_count: %u\n",
> +	    vmd->vmd_free_count, vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt);
>  	vm_pageout_oom(VM_OOM_MEM);
>  
>  	/*
> 
> 
> Mark Johnston also mentions "sysctl vm" output as proving more
> contextual information.
> 

The significance of those lines isn't totally lost on me, but 
it's not obvious how to apply them. Any guidance appreciated! 


Thanks for reading,

bob prohaska




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180801034511.GA96616>