From owner-freebsd-arch@FreeBSD.ORG Thu Nov 22 12:10:03 2007 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 E58B416A46B for ; Thu, 22 Nov 2007 12:10:03 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 6E1E713C4EB for ; Thu, 22 Nov 2007 12:10:03 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so2498993nfb for ; Thu, 22 Nov 2007 04:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=RaTKZQlpQ4iVassyC522YE6RPMJnqJ7t9LnS+WEqRFY=; b=PUHp8i+/zSt8f5dUEX6LH0hyZl/HgwKbNHLrhMenknHT00yIewwB48BVswZj+h74oPFhgylqawfOnkSC0RHx3fanrw3h62dh3at16XZL66ZgMZ0q/iSrYQcY3BcgGWviVQ6NUmGM4Vvt7IU8a6HQyAVMGGw2jPl4zEtN89id/NM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=OuFrxbmwGi3aseXxd5Mpw3Tt80E7G1mmm0vm/AkXZYU4RFWRFBEkCXT6ffiMTbQzFrhpY3I7vZvcNw6WKsuUqMvw+xa+/fZgAEg8bpfWNoWDgfct6pgJS03b4d6FqTTmdxI9UPL9N0WdfpP+YiX0kdE3vD3EuoVgeGLleh20xRM= Received: by 10.86.54.3 with SMTP id c3mr8388055fga.1195731723693; Thu, 22 Nov 2007 03:42:03 -0800 (PST) Received: by 10.86.28.19 with HTTP; Thu, 22 Nov 2007 03:42:03 -0800 (PST) Message-ID: <3bbf2fe10711220342i3360f077u2e093a676b1fdbe8@mail.gmail.com> Date: Thu, 22 Nov 2007 12:42:03 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Alfred Perlstein" In-Reply-To: <20071121222319.GX44563@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071121222319.GX44563@elvis.mu.org> X-Google-Sender-Auth: d9d43e22c4144d87 Cc: arch@freebsd.org 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 12:10:04 -0000 2007/11/21, Alfred Perlstein : > 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. As we alredy discussed on IRC, I'm for assuming no recursion on readers (recursion on writers doesn't play any role here, so it is ok maintaining the current behaviour) and adding a mechanism to WITNESS in order to catch cases where such condition is violated. In this way we don't penalyze fast cases. Do you alredy have a patch for the wakeup / sleeping algorithm? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein