From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 17:22:56 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE3C2106566B; Mon, 14 Nov 2011 17:22:55 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E1D0A8FC0A; Mon, 14 Nov 2011 17:22:54 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA08690; Mon, 14 Nov 2011 19:22:52 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EC14E63.2090506@FreeBSD.org> Date: Mon, 14 Nov 2011 19:22:43 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kostik Belousov References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <4EC0E838.50609@FreeBSD.org> <20111114130857.GC50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111114130857.GC50300@deviant.kiev.zoral.com.ua> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5D8E014BB4D54A54E4F13B1A" Cc: arch@FreeBSD.org, current@FreeBSD.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 17:22:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5D8E014BB4D54A54E4F13B1A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable on 14/11/2011 15:08 Kostik Belousov said the following: > On Mon, Nov 14, 2011 at 12:06:48PM +0200, Andriy Gapon wrote: >> On a more serious note: >> - some code in my latest version of the patch was contributed by or wa= s based >> on the code or ideas contributed by jhb and mdf (so that attributions = are not >> lost) Oops, forgot the most recent and quite big contribution from Attilio. > Please provide me with proper attribution for contributors and testers.= My memory has faded a bit, so let's make it simple. In cooperation with: attilio, avg, jhb, kib, mdf Tested by: avg, Eugene Grosbein , gnn, Steven Hartland , glebius, kib [strike out obvious/unnecessary] >> - there was a concern about how sync-on-panic would work >> >> About the latter, I have never really tested it. mdf has suggested to >> move the sync-on-panic code to a place after we ensure that there is >> only one CPU in panic(), but before we stop other CPUs. > sync_on_panic is incompatible with the patch. I argue that it provides > non-zero chance of damaging good filesystems even if panic was unrelate= d > to the fs/bio/device layer. As an example, consider the case when other= > CPU was modifying in-memory representation of the metadata, and panic > happen on this CPU. If you write half-changed block back, you make more= > damage to the filesystem then if you do not. The half-backed sync spoil= s > any journaling or SU consistency guarantees. Not sure how this is different from what we have right now (without the p= atch). Perhaps I misunderstand what you say, but, just in case, the proposal was= to do sync-on-panic before stopping other CPUs. > The issues of multithreading nature of our storage subsystem are second= ary. >=20 > The user who sets either tunable shall know what he does. That has always been the case. and apparently there are people who still want this option to exist. >> I think that I've already sent you a list of the early testers for >> various WIP versions of the patch. > I do not have the list. Included above. > BTW, if you want, feel free to handle the commit youself. You definitel= y > spent much more efforts on the stuff and deserve the credit. >=20 > I was promised in private that a review will be provided during this > weekend. Unfortunately too little time and spare mind capacity to do the commit no= w. I do not care much about the credit (or commit-o-meter) as long as we get= functionality in. It was/is a collective effort in any case. Besides I won't be able to handle any potential regression reports in a sufficiently speedy manner. --=20 Andriy Gapon --------------enig5D8E014BB4D54A54E4F13B1A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOwU5sAAoJEHSlLSemUf4vt/gIAK3ErPHwuIpwBFvSjvgP0OQF clr4Ox7yl8MfvXej43nqRnj00ySRpqpFT+kAbruKlnkiPJoIeD4DOJr1eMSi1/CD lt8J5guUPIon/or5V/e703jnv/KTaR63d2ihHZg9y1GVWww2iFZTamg4M46aGtF5 Y83J1tBWOROEy9MaFHGtyBSaQBgAMIpMLnY+L1ueXerzAaCfXVlXT4osEt95fJRg hPhfgfWK6CDwswwo01aom0x7bVl+xA5rXDUFpDVD8LDcGjpYVAstH181Uh4sO69w 61wQTaC7G9b+1jOx8eALK8k1ssBFamwaJ/pcmsBbXrvBUJCFgdb8wzwX0ZlZGb0= =o+eV -----END PGP SIGNATURE----- --------------enig5D8E014BB4D54A54E4F13B1A--