From owner-freebsd-arch@FreeBSD.ORG Thu Nov 22 15:46:17 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0965E16A417; Thu, 22 Nov 2007 15:46:17 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 83A7413C45D; Thu, 22 Nov 2007 15:46:16 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-066-042-157.pools.arcor-ip.net [88.66.42.157]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1IvEAG21rY-0002TY; Thu, 22 Nov 2007 16:40:28 +0100 From: Max Laier Organization: FreeBSD To: freebsd-arch@freebsd.org Date: Thu, 22 Nov 2007 16:40:51 +0100 User-Agent: KMail/1.9.7 References: <20071121222319.GX44563@elvis.mu.org> In-Reply-To: <20071121222319.GX44563@elvis.mu.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1509446.0MGOy2rOSm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711221641.02484.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19M5TllSccag4YS7BrKGwBHGR4wXCe3wDR3geT pEbz5/6S+GU2H7X36d6z3Pk+jUQqXpT4B4lSZ7nGYe+ZhvzVo+ AAdPjALACHIOn/m4DUwSm5x0VqsMqxCW4XjA6984fk= Cc: attilio@freebsd.org, Stephan Uphoff , Alfred Perlstein Subject: Re: rwlocks, correctness over speed. 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: Thu, 22 Nov 2007 15:46:17 -0000 --nextPart1509446.0MGOy2rOSm Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 21 November 2007, Alfred Perlstein wrote: > In summary, I am proposing (temporarily) making read-recursion > on rwlocks not supported in order to avoid livelock due to writer > starvation. > > More details: > > We currently have a problem with our implementation of rwlocks. > > I think this is a key issue for 7.x as what we decide to support > will have rammifications for many years to come. > > We do not support writer priority or "fair share" usage of rwlocks > between readers and writers. > > We have several choices to rectify this. > > 1. Disallow recursion on rwlocks (witness can be used to enforce this), > this simplifies rwlocks such that we can avoid deadlock when a single > reader is trying to recurse while a writer is pending. > > 2. Track ownership of rwlocks, this can be implemented with a "rwlock > stack" in the per-thread control block (struct thread). Using this > ownership information we can determine if someone is recursing and > allow them to continue recursing despite a pending write request. > > I think the most simple solution currently is to drop support for > recursive reads on rwlocks until we have the facility in place > to properly support starvation avoidance. > > Why is this important? > > Simply put, developers that quickly "fix" some portion of code, > whether that be a driver or part of the kernel proper who use read > recursion will open the system to writer starvation and hence the > system will destabilize, particulary for high load situations. > > I would like to get this in before 7.0-RELEASE becasue otherwise > we're forced to implement something like the above mentioned solution > #2, which will degrade performance for most use cases of rwlocks. > > Comments? rwlocks are already used in places that do recursive reads. The one place= =20 I'm certain about is pfil(9) and we need a proper sollution for this. =20 Before rwlocks were used, I had a handrolled locking that supported both=20 read/write semantics and starvation avoidance - at the cost of failing to=20 allow futher read access when a writer asked for access. This however,=20 was quite application specific and not the most efficient implementation=20 either. If we were to disallow read recursion, we should have some generic lock=20 type that does allow it. rmlock(9)s seem to support full priority=20 propagation even for recursed readers. Can they be MFCed so that we have=20 an alternative? Are they considered ready for production? Should we=20 switch pfil(9) to them? It seems like a perfect match. Obviously rmlocks are not a general replacement for rwlocks, but in the=20 case of pfil they are the even better fit. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1509446.0MGOy2rOSm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHRaMOXyyEoT62BG0RAtQVAJ9smaoqoOsMT9pBENSunGrceFSNxgCfcOJu RtJGG6S6YmCYlXdxl7GyKcg= =68y9 -----END PGP SIGNATURE----- --nextPart1509446.0MGOy2rOSm--