From owner-svn-src-head@FreeBSD.ORG Sat Aug 30 17:37:53 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31F0B68B; Sat, 30 Aug 2014 17:37:53 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [IPv6:2001:470:67:39d::78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EFFDA12FF; Sat, 30 Aug 2014 17:37:52 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 8F89A37A; Sat, 30 Aug 2014 10:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1409420271; bh=o5VqUEzC+dl6Yc4ojfYrdmShl7JDJw3HSUa+fiuMdBY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=i8hXhka5rjv8cwBR0hADQIcwkbjfEAAApWcJTsVVVEIFhr9xqUnbCWub/jYZK19uF iHLDK4WLGHBAV3FSZ07YbkTW2IJDNERl38QR4ZB9mH3XkyLr6ZQZ/8Ox5q9g+d0AX6 taEioxDn4JZT4wjc2h5KFc0Xm8ZJVhw1a5jxbo3I= From: Peter Wemm To: Steven Hartland Subject: Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm Date: Sat, 30 Aug 2014 10:37:43 -0700 Message-ID: <39211177.i8nn9sHiCx@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <201408281950.s7SJo90I047213@svn.freebsd.org> <2714752.cWQfguSlQD@overcee.wemm.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart23165865.b7KFKC409C"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: src-committers@freebsd.org, Alan Cox , svn-src-all@freebsd.org, Dmitry Morozovsky , "Matthew D. Fuller" , svn-src-head@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 17:37:53 -0000 --nextPart23165865.b7KFKC409C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Saturday 30 August 2014 02:03:42 Steven Hartland wrote: > ----- Original Message ----- > From: "Peter Wemm" >=20 > > On Friday 29 August 2014 21:42:15 Steven Hartland wrote: >=20 > > If this function returns non-zerp, ARC is given back: > >=20 > > static int > > arc_reclaim_needed(void) > > { > >=20 > > if (kmem_free_count() < zfs_arc_free_target) { > > =20 > > return (1); > > =20 > > } > > =20 > > /* > > * Cooperate with pagedaemon when it's time for it to scan > > * and reclaim some pages. > > */ > > =20 > > if (vm_paging_needed()) { > > =20 > > return (1); > > =20 > > } > >=20 > > ie: if v_free (ignoring v_cache free pages) gets below the threshol= d, > > stop > > evertyhing and discard ARC pages. > >=20 > > The vm_paging_needed() code is a NO-OP at this point. It can never > > return > >=20 > > true. Consider: > > vm_cnt.v_free_target =3D 4 * vm_cnt.v_free_min + > >=20 > > vm_cnt.v_free_reserved; > > vs > >=20 > > vm_pageout_wakeup_thresh =3D (vm_cnt.v_free_min / 10) * 11;= > >=20 > > 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. > >=20 > > vm_paging_needed() compares the total free pool (v_free + v_cache) > > against the > > smaller wakeup threshold - 110% of v_free_min. > >=20 > > Comparing a larger value against a smaller target than the previous= > > test will > > never succeed unless you manually change the arc_free_target sysctl= . >=20 > 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 alre= ady > been tested and didn't work well. And Karl also said that his tests are on machines that have no v_cache,= so=20 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 prob= lems=20 you're using as a justtification for the changes. Your own testers have admitted that they don't test the scenario that t= he=20 problem exists with. > > Also, what about the magic numbers here: > > u_int zfs_arc_free_target =3D (1 << 19); /* default before pagedaem= on > > init only */ >=20 > That is just a total fall back case and should never be triggered unl= ess > as the comment states the pagedaemon isn't initialised. >=20 > > That's half a million pages, or 2GB of physical ram on a 4K page si= ze > > system > > How is this going to work on early boot in the machines in the clus= ter > > with > > less than 2GB of ram? >=20 > Its there to ensure that ARC doesn't run wild ARC for the few > milliseconds > / seconds before pagedaemon is initalised. >=20 > 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 wit= h file=20 system and VM - critical parts of the system. This is NOT the place to= be=20 screwing around with things you don't understand. alc@ was trying to b= e=20 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 comm= it. =20 I'm almost at the point where I want to ask for the whole thing to be b= acked=20 out. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart23165865.b7KFKC409C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----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----- --nextPart23165865.b7KFKC409C--