From owner-freebsd-arch@FreeBSD.ORG Sat Nov 24 16:17:11 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 3118A766; Sat, 24 Nov 2012 16:17:11 +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 11D648FC13; Sat, 24 Nov 2012 16:17:10 +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 29AD91A3C1A; Sat, 24 Nov 2012 08:17:10 -0800 (PST) Message-ID: <50B0F306.6020906@mu.org> Date: Sat, 24 Nov 2012 08:17:10 -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: 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 16:17:11 -0000 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. This is not what people should think about FreeBSD, it will drive developers away. Heck, I'm scared now to even write anything. -Alfred