From owner-freebsd-stable@FreeBSD.ORG Sat Jan 8 20:20:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 568EE106564A; Sat, 8 Jan 2011 20:20:33 +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 C1C7B8FC08; Sat, 8 Jan 2011 20:20:32 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p08KKTNC011590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Jan 2011 22:20:29 +0200 (EET) (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.4/8.14.4) with ESMTP id p08KKTTl095773; Sat, 8 Jan 2011 22:20:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p08KKSDq095772; Sat, 8 Jan 2011 22:20:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 8 Jan 2011 22:20:28 +0200 From: Kostik Belousov To: Lev Serebryakov Message-ID: <20110108202028.GY12599@deviant.kiev.zoral.com.ua> References: <204344488.20110108214457@serebryakov.spb.ru> <20110108190232.GU12599@deviant.kiev.zoral.com.ua> <1792026896.20110108222909@serebryakov.spb.ru> <20110108195613.GW12599@deviant.kiev.zoral.com.ua> <1544327450.20110108231021@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WzyiqVXNYYkrrY2o" Content-Disposition: inline In-Reply-To: <1544327450.20110108231021@serebryakov.spb.ru> 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=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: 8.2-PRERELEASE: live deadlock, almost all processes in "pfault" state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 20:20:33 -0000 --WzyiqVXNYYkrrY2o Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 08, 2011 at 11:10:21PM +0300, Lev Serebryakov wrote: > Hello, Kostik. > You wrote 8 =D1=CE=D7=C1=D2=D1 2011 =C7., 22:56:13: >=20 >=20 > >> And, if it is "classic deadlock" is here any "classical" solution to > >> it? > > Do not allocate during bio processing. > So, if GEOM need some cache, it needs pre-allocate it and implements > custom allocator over allocated chunk? :( >=20 > And what is "bio processing" in this context? geom_raid5 puts all bio processing =3D=3D whole time needed to finish pageout. Pageout is often performed to clean the page to lower the page shortage. If pageout requires more free pages to finish during the shortage, then we get the deadlock. Also, it seems that you allocate not only bios (small objects, not every request cause page allocation), but also the huge buffers, that require free pages each time. > bios into the (private, internal) queue and geom_start() exits > immediately, and bio could spend rather long time in queue (if it is > write request) before it will be sent to underlying provider. And, > yes, it could be combined with other bios to form new one (why > allocation of new bio is needed). >=20 > So, is "bio processing" a whole time before bio is complete, or only > geom_start() call or what? >=20 > Also, RAID5 needs to read data (other stripes) and write data (new > checksum) when "write" bio is processed. BTW, "system" geom_raid3 and > geom_vinum (with raid5 volume) need to do the same to maintain > checksums, so they could deadlock (in theory) too, if problem is > "allocate memory during bio processing". And geom_mirror needs > allocate bio for second (third, ...) component on every write... >=20 > --=20 > // Black Lion AKA Lev Serebryakov >=20 --WzyiqVXNYYkrrY2o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0oxwwACgkQC3+MBN1Mb4gPTQCgiL9vRWFvfd1a17Rssv9jmGt6 1xAAoI4StIuJ6/eCiriinVyGrzA3si9a =Fw1y -----END PGP SIGNATURE----- --WzyiqVXNYYkrrY2o--