From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 00:38:27 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 732ADE2 for ; Sun, 25 Nov 2012 00:38:27 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id E615C8FC08 for ; Sun, 25 Nov 2012 00:38:26 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so7035297lbb.13 for ; Sat, 24 Nov 2012 16:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/fDwuhRJ5NlhP1D5yT2GtmYGvES3Bdto3xJV1wHh2Z8=; b=IsMC7O0j4JFX8bKVe7Bf2qiq+CpdB06GHkzh9aCCFaWlX6lNpD9ss8oY6Kw9Mn3piN FWiS2a5IeVI7cKr8YUKGgrjl/6JKXCxuxwYZYjbfebwCQSf37/Ts7LKNKs1DU4D82rLe +eN+mxA7Wg6MPGwbxDLeENvEfB6/8ApnPiIFpEq3r1XfzOiu8MDwFDWkbeoBNBDofSVM Vp23U7uOPbllvR2Sg44j+RGznokAyJwUiabRe37XtzBw2jfBfJIGQ+Woe/lCRKALn3Kc v4XeRKUGApmdqSsSP31bP/hz5GuhCWjSP1plKZczJ9yiMPFINbyh5yrjX3kpxJ6W8tTh /yaQ== MIME-Version: 1.0 Received: by 10.152.104.50 with SMTP id gb18mr7253935lab.9.1353803905573; Sat, 24 Nov 2012 16:38:25 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Sat, 24 Nov 2012 16:38:25 -0800 (PST) In-Reply-To: <50B145C5.8070503@mu.org> References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <50B145C5.8070503@mu.org> Date: Sun, 25 Nov 2012 00:38:25 +0000 X-Google-Sender-Auth: VxgSE5DyJ2FBCacJrWGSlM8SYEI Message-ID: Subject: Re: [RFC] sema_wait_sig From: Attilio Rao To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: Mark Linimon , Oleksandr Tymoshenko , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 00:38:27 -0000 On Sat, Nov 24, 2012 at 10:10 PM, Alfred Perlstein wrote: > I don't understand why you are the one who is so upset. Your first email to > me implied that I had 0 smp experience. > > Let me explain why this rototilling is unneeded. > > Go download a copy of linux and observe the following: > spin_lock(&mb_cache_spinlock); > spin_unlock(&mb_cache_spinlock); > spin_lock_irqsave, spin_unlock_irqrestore > up() > down(dqio_mutex) > > Those apis have been available for a decade at least. > > I'll cut to the point on this. > > If you want to change HOW the underlying freebsd SMP api works to improve > performance, then please do! > > But if you want to change the actual KPI, then please realize that Linux SMP > does darn well with a KPI for SMP that's pretty much unchanged for nearly 10 > years. > > I would venture to say in this respect we've become what we used to mock > Linux for, an OS that gratuitously changes interfaces for the sake of what > is cool, versus what our vendors need. Keeping old mechanisms/duplicate/etc. around just because they existed 10 years ago is not a good reason once their KPI is not only redundant but also dangerous. And this seems to be your only "technical" reason opposed to my proposals. Using disown for lockmgr is something very dangerous which should not be used out of his specific case for the buffer cache. I really don't want to incourage its use out of that and I'm sure people can build very dangerous policies using it (this is just an example, but it explains my point, I think). Maybe my proposed changes of mtx against rwlock are a bit too extreme, I could understand that and I'm very open on changing my mind on it, but I don't understand how would be useful to keep lockmgr() and sema() around honestly. It is just a burden of code duplication (in some places) and dangerous KPI (in other). Attilio -- Peace can only be achieved by understanding - A. Einstein