From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 01:16:17 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 E21F4566 for ; Sun, 25 Nov 2012 01:16:17 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 577278FC13 for ; Sun, 25 Nov 2012 01:16:17 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so9639310lah.13 for ; Sat, 24 Nov 2012 17:16:15 -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=3LlfjVcIGuc19aXdqrUN1aVgQc+RE22lyB9+1b6zEH0=; b=bjYrTYoO1dnXcouHWc4Zb0IVHWc5WbC6ecT2WpMVqrjkX2TUxgie/rRH85Lbor4Xgl VFOltQj1ZB8OZdqAgOBX04MYKZvE34fUNFQJaBz9w7UcQiRHhlkV7WDU+X7z7JSyvEY6 LyUjAhqgwEl2r1uo+hCC0HoUIHnnHkv/IH196G8BInQo2HEym6qV785LZWkRHrt/8DYr yuUDyZVDo3Ye8gB6AOXdl6GN2WHZTH+5Xt9Z+35+B9gAkrNLWXAaKPtJ/8QgdN2lXp9g /Whl+x2i70vr4Qa5x0/PhYhxqecx2eaKa4gE45axCFVKCnm+jCE6uKy/q5Oyjr/iyYQv pg8w== MIME-Version: 1.0 Received: by 10.152.110.234 with SMTP id id10mr7179105lab.15.1353806175256; Sat, 24 Nov 2012 17:16:15 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Sat, 24 Nov 2012 17:16:15 -0800 (PST) In-Reply-To: <50B16E7A.60900@mu.org> References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <50B145C5.8070503@mu.org> <50B16E7A.60900@mu.org> Date: Sun, 25 Nov 2012 01:16:15 +0000 X-Google-Sender-Auth: bnJXC0ULBLMNLtiadV_XRypGRJo 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 01:16:18 -0000 On Sun, Nov 25, 2012 at 1:03 AM, Alfred Perlstein wrote: > 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? Did you see also how they are used? In some places they have a counter of 1, which means they can be effectively replaced by an sx lock. In all the other places, they are used with a counter of 0, which means they can be effectively replaced by mtx and sleep. Can you giving me a reason on why really keeping them? Also, if you think they would help a Linux compat shim layer, keep in mind the following: - a plan for something like that has been discussed for years and by several people and nothing concrete, happened, with a lot of disagreement (both technical and philosophical) - there is no plan for doing so in the foreeable future, neither there is agreement it is really a good idea. So you prefer to have completely redundant (and unused in the end) code just because it may or may not happen to help a compat layer that doesn't exist and maybe will never exits? Please answer openly. > > 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. I don't agree, I would just like to have a clean KPI and force people to do right things. That clean KPI already exists, we just need to conver current consumers in doing their dirtiness in "controled environment". Attilio -- Peace can only be achieved by understanding - A. Einstein