From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 18:02:56 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 6DA89C2F; Sat, 24 Nov 2012 18:02:56 +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 42A2D8FC0C; Sat, 24 Nov 2012 18:02:56 +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 A1A381A3C56; Sat, 24 Nov 2012 10:02:55 -0800 (PST) Message-ID: <50B10BCF.3080407@mu.org> Date: Sat, 24 Nov 2012 10:02:55 -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: <50B0F306.6020906@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Oleksandr Tymoshenko 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: Sat, 24 Nov 2012 18:02:56 -0000 On 11/24/12 8:21 AM, Attilio Rao wrote: > On Sat, Nov 24, 2012 at 4:17 PM, Alfred Perlstein wrote: >> On 11/24/12 7:21 AM, Attilio Rao wrote: >>> On Sat, Nov 24, 2012 at 3:03 PM, Attilio Rao wrote: >>>> On Fri, Nov 23, 2012 at 6:12 AM, Oleksandr Tymoshenko >>>> wrote: >>>>> Hello, >>>>> >>>>> Is there any particular reason FreeBSD does not have sema_wait_sig >>>>> function? It seems to be easily implementable using cv_wait_sig >>>>> function. >>>> The sema(9) primitive is considered obsolete/dying. >>>> You should really use mtx + condvar (so just go using cv_wait_sig() >>>> directly). >>>> >>>> I had a patch to remove it all from the kernel few years ago but I >>>> never got to commit it. >>>> It would be good if we can remove this primitive off before 10.0. >>> Before to start receiving bikeshead e-mails by "savers of the nation", >>> let me explain this a bit. This cames directly from the necessity to >>> shrunk the number of locking primitives we offer, in particular when >>> such primitives have very naive/non-standard interface, meant as >>> dangerous and not intuitive KPI. >>> The biggest 2 beasts to chase are then sema(9) and lockmgr(9). >>> >>> The former should be replaced by a smart use of mtx + flags/counters + >>> sleep(9)/condvar(9). I see some of the usage are the ones that want >>> the first locker to sleep (counter as 0 at init time), for example. >>> >>> The latter should be replaced by sx(9) interface, but that's very >>> tricky. lockmgr have a lot of strange patterns which require a fair >>> bit of understanding and work to be controlled (LK_DRAIN, >>> LK_SLEEPFAIL, interlock handling, lockmgr_disown(), etc.). I'm sure sx >>> might grow up some further operations to cope with it (namely the >>> interlock and maybe disowning) but that's really minor turbolence as >>> removing redundant lockmgr would be a big win for us. Right now it is >>> just a burden and more code to maintain for a very little gain. >>> >>> As a last item, we may also look at splitting the sleep-mtx and >>> spin-mtx interface and replace all the occurence of the former with >>> rwlocks, of course always held in write mode. This way the mtx(9) will >>> only serve spinlocks and their implementation will be very self >>> contained. >>> >>> Thanks, >>> Attilio >>> >>> >> People have been trying to "kill lockmgr" for 5+ years now. >> >> In the meanwhile discouraging people from using things that make their lives >> easier in porting drivers is probably wrong. >> >> According to this post I shouldn't touch anything that has to do with any >> SMP stuff until you complete your upcoming work because it will all be >> turned upside down. > I don't have any plan to do it right now and if you want to follow > this you are welcome. > If you do want to do something else (like adding sema_wait_sig()) I'm > opposed to it and I'm giving you my opinion on why. > > You can do what you want then, but at least I'm free to say publically > what I think should be done to have correct code, or should I just let > people which have 0 history of contributing to SMP just turn upside > down all the last 15 years of work? > > Attilio > > Attilio, Please grep smp in http://people.freebsd.org/~alfred/alfred.logs.txt. It's not a lot, but it was when we first started going SMP and I worked very hard on this. Select locking, Filedesc locking, struct file... :) I guess this is a nice welcome back to the project. :) -Alfred