From owner-svn-src-projects@FreeBSD.ORG Mon May 14 11:13:55 2012 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D468E106564A; Mon, 14 May 2012 11:13:55 +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 6D2818FC12; Mon, 14 May 2012 11:13:55 +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 q4EBDpN9071579; Mon, 14 May 2012 14:13:51 +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 q4EBDoY7029587; Mon, 14 May 2012 14:13:50 +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 q4EBDoAx029586; Mon, 14 May 2012 14:13:50 +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: Mon, 14 May 2012 14:13:50 +0300 From: Konstantin Belousov To: Grzegorz Bernacki Message-ID: <20120514111350.GF2358@deviant.kiev.zoral.com.ua> References: <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> <4FB10305.5020002@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Gm1kdWufJAYSdyi4" Content-Disposition: inline In-Reply-To: <4FB10305.5020002@freebsd.org> 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, src-committers@freebsd.org, Mateusz Guzik 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: Mon, 14 May 2012 11:13:55 -0000 --Gm1kdWufJAYSdyi4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 14, 2012 at 03:05:09PM +0200, Grzegorz Bernacki wrote: > On 05/11/12 17:48, 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 > >>> > >>>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. > >> > >>As I understand, in your situation with lot of managed buffers, the dir= ty > >>queue could be just empty. > > > >I don't think I follow. Is your concern that with a lot of managed buffe= rs=20 > >and > >empty dirty queue nothing can be recycled? Or that managed buffers > >affect calls to buf_do_flush? > > > >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. > > */ > > > > if (bp =3D=3D NULL) { > > > >Conditions that cause bufdaemon weakups/buf_do_flush calls seem to be > >not dependent on buffers being managed or not. > > > >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. > > > >If I'm wrong or misunderstood you, please elaborate on problem you have > >in mind. > > > >>> > >>>Example proof-of-concept (will be cleaned up) change for nandfs: > >>>http://people.freebsd.org/~raj/patches/misc/nandfs_vfs_highdirtybuf.di= ff > >>> > >>>Does this look reasonable? > >>> > > >=20 >=20 > Hi Kostik, >=20 > We would like to merge our code into HEAD. Please let us know if you=20 > have any objection. We are still going to work on buf deamon changes,=20 > but we would like to avoid delay on pushing our changes into HEAD. >=20 > As I understand we agreed that we can merge B_MANAGED change from: > http://people.freebsd.org/~gber/patches/vfs_bio2.diff Yes, I have no objections against vfs_bio2.diff. --Gm1kdWufJAYSdyi4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+w6O4ACgkQC3+MBN1Mb4gmVQCgsrBMcvpTsZV/Qasl4Qk6v/DI laQAn0OUl4lQx3vjIgvwPM8TCKm/LGca =HPYb -----END PGP SIGNATURE----- --Gm1kdWufJAYSdyi4--