From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 01:03:54 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 D919A476; Sun, 25 Nov 2012 01:03:54 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B2ABF8FC0C; Sun, 25 Nov 2012 01:03:54 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 45D291A3C1A; Sat, 24 Nov 2012 17:03:54 -0800 (PST) Message-ID: <50B16E7A.60900@mu.org> Date: Sat, 24 Nov 2012 17:03:54 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: [RFC] sema_wait_sig References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <50B145C5.8070503@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Linimon , Oleksandr Tymoshenko , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list 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 01:03:55 -0000 On 11/24/12 4:38 PM, Attilio Rao wrote: > 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. Whoa, wait a second. A user just proposed using the infrastructure to port linux drivers. Additionally the following subsystems make use of sema(9): inifiband stack (linux compat shim). sysv ipc. ata. opensolaris compat shim. xfs. What would be the point of removing this KPI? Those consumers would then just have to roll their own. Wouldn't that lead to duplicate code? 176 sys/kern/kern_sema.c It's not really a lot of code. > 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). I agree that lockmgr is a very dangerous beast. Whatever that can be done to get rid of the complexity would be good. If we could hide some of the lockmgr "features" behind a "I know what i'm doing fence" or maybe a "only to be used with filesystem code" fence that might be good. -Alfred