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 <jroberson_at_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 ?Received on Sun Mar 25 2018 - 08:42:07 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:15 UTC