On Fri, Mar 23, 2018 at 04:21:32PM -0700, Bryan Drewery wrote:

> On 3/20/2018 12:07 AM, Peter Jeremy wrote:
> > 
> > On 2018-Mar-11 10:43:58 -1000, Jeff Roberson <jrober...@jroberson.net> 
> > wrote:
> >> Also, if you could try going back to r328953 or r326346 and let me know if 
> >> the problem exists in either.  That would be very helpful.  If anyone is 
> >> willing to debug this with me contact me directly and I will send some 
> >> test patches or debugging info after you have done the above steps.
> > 
> > I ran into this on 11-stable and tracked it to r326619 (MFC of r325851).
> > I initially got around the problem by reverting that commit but either
> > it or something very similar is still present in 11-stable r331053.
> > 
> > I've seen it in my main server (32GB RAM) but haven't managed to reproduce
> > it in smaller VBox guests - one difficulty I faced was artificially filling
> > ARC.
> > 
> 
> Looking at the ARC change you referred to from r325851
> https://reviews.freebsd.org/D12163, I am convinced that ARC backpressure
> is completely broken. On my 78GB RAM system with ARC limited to 40GB and
> doing a poudriere build of all LLVM and GCC packages at once in tmpfs I
> can get swap up near 50GB and yet the ARC remains at 40GB through it
> all.  It's always been slow to give up memory for package builds but it
> really seems broken right now.

Can you test: revert all 'needfree' related commits and applay
https://reviews.freebsd.org/D7538 ?

_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to