From owner-svn-src-projects@FreeBSD.ORG Thu May 17 22:30:46 2012 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8CF61065670; Thu, 17 May 2012 22:30:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 47B4C8FC15; Thu, 17 May 2012 22:30:46 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q4HMUGh7043103; Fri, 18 May 2012 01:30:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q4HMU16v032247; Fri, 18 May 2012 01:30:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q4HMTkKC032242; Fri, 18 May 2012 01:29:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 18 May 2012 01:29:46 +0300 From: Konstantin Belousov To: Mateusz Guzik Message-ID: <20120517222946.GA2358@deviant.kiev.zoral.com.ua> References: <20120317161050.GI75778@deviant.kiev.zoral.com.ua> <4FA8FFB9.7090002@freebsd.org> <20120508095631.GV2358@deviant.kiev.zoral.com.ua> <4FA94609.3060306@freebsd.org> <20120510103105.GG2358@deviant.kiev.zoral.com.ua> <4FABC64F.3060502@freebsd.org> <20120510115857.GH2358@deviant.kiev.zoral.com.ua> <20120510164519.GA13258@pcbsd-2342.semihalf.com> <20120511104648.GM2358@deviant.kiev.zoral.com.ua> <20120511154810.GA99005@pcbsd-2342.semihalf.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="utUizcr4eQAkV3Ky" Content-Disposition: inline In-Reply-To: <20120511154810.GA99005@pcbsd-2342.semihalf.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: svn-src-projects@freebsd.org, Grzegorz Bernacki , src-committers@freebsd.org Subject: Re: svn commit: r233072 - projects/nand/sys/kern X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 22:30:47 -0000 --utUizcr4eQAkV3Ky Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 11, 2012 at 05:48:10PM +0200, Mateusz Guzik wrote: > On Fri, May 11, 2012 at 01:46:48PM +0300, Konstantin Belousov wrote: > > On Thu, May 10, 2012 at 06:45:19PM +0200, Mateusz Guzik wrote: > > > http://people.freebsd.org/~raj/patches/misc/vfs_highdirtybuf.diff > > >=20 > > > callbacks are expected to increase flushed counter if they happend to > > > flush some buffers. > > I do not think this is right. You need to call a routine when getnewblk= () > > is unable to find a buffer to recycle. > >=20 > > As I understand, in your situation with lot of managed buffers, the dir= ty > > queue could be just empty. >=20 > I don't think I follow. Is your concern that with a lot of managed buffer= s and > empty dirty queue nothing can be recycled? Or that managed buffers > affect calls to buf_do_flush? >=20 > I presume you talk about the code below the following: > /* > * If we exhausted our list, sleep as appropriate. We may have to > * wakeup various daemons and write out some dirty buffers. > * > * Generally we are sleeping due to insufficient buffer space. > */ >=20 > if (bp =3D=3D NULL) { >=20 > Conditions that cause bufdaemon weakups/buf_do_flush calls seem to be > not dependent on buffers being managed or not. My concern is that you use unappropriate terminology at first, and this leads to mostly no-op code as a consequence. If you use managed buffers, not only you should flush dirty buffers when bufdaemon is kicked, but you also need to actually return some buffers to the clean or empty queues. Otherwise, the condition which caused getnewbuf() allocation failure will persist. >=20 > buf_do_flush with our change always calls registered callbacks and the > callback that we register calls code that knowns what nandfs managed > buffers are dirty and flushes those. Buffers from dirty queues (if any) > are flushed separately. >=20 > If I'm wrong or misunderstood you, please elaborate on problem you have > in mind. >=20 > > >=20 > > > Example proof-of-concept (will be cleaned up) change for nandfs: > > > http://people.freebsd.org/~raj/patches/misc/nandfs_vfs_highdirtybuf.d= iff > > >=20 > > > Does this look reasonable? The vfs_bio.c change is probably fine, but I have doubts that nandfs patch will change anything for the reasons I described above. On the other hand, I did not read nandfs code, so I may be wrong. --utUizcr4eQAkV3Ky Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+1e9kACgkQC3+MBN1Mb4izIQCfVCG/GvPIR3KtZaWVCSmIB2QL ly4AnRyZ1VB4X+SW1Usc7pQVK54jWmYB =XE4x -----END PGP SIGNATURE----- --utUizcr4eQAkV3Ky--