Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 30 Aug 2014 10:37:43 -0700
From:      Peter Wemm <peter@wemm.org>
To:        Steven Hartland <smh@freebsd.org>
Cc:        src-committers@freebsd.org, Alan Cox <alc@rice.edu>, svn-src-all@freebsd.org, Dmitry Morozovsky <marck@rinet.ru>, "Matthew D. Fuller" <fullermd@over-yonder.net>, svn-src-head@freebsd.org
Subject:   Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
Message-ID:  <39211177.i8nn9sHiCx@overcee.wemm.org>
In-Reply-To: <E0F163ECBF5E407F99AFDB18FAB05C58@multiplay.co.uk>
References:  <201408281950.s7SJo90I047213@svn.freebsd.org> <2714752.cWQfguSlQD@overcee.wemm.org> <E0F163ECBF5E407F99AFDB18FAB05C58@multiplay.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help

[-- Attachment #1 --]
On Saturday 30 August 2014 02:03:42 Steven Hartland wrote:
> ----- Original Message -----
> From: "Peter Wemm" <peter@wemm.org>
> 
> > On Friday 29 August 2014 21:42:15 Steven Hartland wrote:

> 
> > If this function returns non-zerp, ARC is given back:
> > 
> > static int
> > arc_reclaim_needed(void)
> > {
> > 
> >         if (kmem_free_count() < zfs_arc_free_target) {
> >         
> >                 return (1);
> >         
> >         }
> >         
> >          /*
> >          * Cooperate with pagedaemon when it's time for it to scan
> >          * and reclaim some pages.
> >          */
> >         
> >         if (vm_paging_needed()) {
> >         
> >                 return (1);
> >         
> >         }
> > 
> > ie: if v_free (ignoring v_cache free pages) gets below the threshold,
> > stop
> > evertyhing and discard ARC pages.
> > 
> > The vm_paging_needed() code is a NO-OP at this point. It can never
> > return
> > 
> > true.  Consider:
> >         vm_cnt.v_free_target = 4 * vm_cnt.v_free_min +
> > 
> > vm_cnt.v_free_reserved;
> > vs
> > 
> >         vm_pageout_wakeup_thresh = (vm_cnt.v_free_min / 10) * 11;
> > 
> > zfs_arc_free_target defaults to vm_cnt.v_free_target, which is 400% of
> > v_free_min, and compares it against the smaller v_free pool.
> > 
> > vm_paging_needed() compares the total free pool (v_free + v_cache)
> > against the
> > smaller wakeup threshold - 110% of v_free_min.
> > 
> > Comparing a larger value against a smaller target than the previous
> > test will
> > never succeed unless you manually change the arc_free_target sysctl.
> 
> I'm aware of the values involved, and as I said what you're proposing
> was more akin to where I started, but I was informed that it had already
> been tested and didn't work well.

And Karl also said that his tests are on machines that have no v_cache, so 
he's not testing the scenario.

The code, as written, is wrong.  It's as simple as that.

The logic is wrong.

You've introduced dead code.

Your code changes introduce a scenario that CAUSES one of the very problems 
you're using as a justtification for the changes.

Your own testers have admitted that they don't test the scenario that the 
problem exists with.

> > Also, what about the magic numbers here:
> > u_int zfs_arc_free_target = (1 << 19); /* default before pagedaemon
> > init only */
> 
> That is just a total fall back case and should never be triggered unless
> as the comment states the pagedaemon isn't initialised.
> 
> > That's half a million pages, or 2GB of physical ram on a 4K page size
> > system
> > How is this going to work on early boot in the machines in the cluster
> > with
> > less than 2GB of ram?
> 
> Its there to ensure that ARC doesn't run wild ARC for the few
> milliseconds
> / seconds before pagedaemon is initalised.
> 
> We can change the value no problem, what would you suggest 1<<16 aka
> 256MB?

Please stop picking magic numbers out of thin air.  You are working with file 
system and VM - critical parts of the system.  This is NOT the place to be 
screwing around with things you don't understand.  alc@ was trying to be 
polite.

> Thanks for all the feedback, its great to have my understanding of
> how things work in this area confirmed by those who know.
>
> Hopefully we'll be able to get to the bottom of this with everyones
> help and get a solid fix for these issues that have plaged 10 into
> 10.1 :)

I'm very disappointed in the attention to detail and errors in the commit.  
I'm almost at the point where I want to ask for the whole thing to be backed 
out.

-- 
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAABAgAGBQJUAgvvAAoJEDXWlwnsgJ4EBDEH/Rv4pgRYMVSMZWd5b4aKqcnS
O2/6Pwi/UWpEbxjWCRArymuomKizJmum0Caik/xPhH03MFEYI72tZEcuNoC2p5jT
z1MWPtyyODHkfrR8f2gDRnhcTH/NNsMbd0LDOhK8lQFzZi/me6iBq8yovpTIfNn7
nZquAPwvd8nJV1uO6QqZi+T6EsV1y7AV6UyJZFyeJV32dIlSlXXDnGVjoZzHS05C
uAFroAeDl7jqtTEY06SBe9q1Y9i4f9UsiTX7cckdEtK4dlLiYaJOVoofZi5YN9Ol
iuIDwpYlGrG+IEgfMeqbbF9gyxcO191y30S/64N2pwUqpRN3oclEyKWSRu8EPq8=
=7zlO
-----END PGP SIGNATURE-----

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