From owner-freebsd-arch@FreeBSD.ORG Sun Jun 1 18:25:33 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F19651065672; Sun, 1 Jun 2008 18:25:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A15648FC2E; Sun, 1 Jun 2008 18:25:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m51INlxD032469; Sun, 1 Jun 2008 12:23:47 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 01 Jun 2008 12:25:24 -0600 (MDT) Message-Id: <20080601.122524.114765121.imp@bsdimp.com> To: rwatson@freebsd.org From: "M. Warner Losh" In-Reply-To: <20080526162427.X26343@fledge.watson.org> References: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> <483AD498.6070207@FreeBSD.org> <20080526162427.X26343@fledge.watson.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, bms@freebsd.org, current@freebsd.org, ade@freebsd.org, net@freebsd.org Subject: Re: HEAD UP: non-MPSAFE network drivers to be disabled X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2008 18:25:33 -0000 In message: <20080526162427.X26343@fledge.watson.org> Robert Watson writes: : : On Mon, 26 May 2008, Bruce M. Simpson wrote: : : >> Given that this is (a) 2008 and (b) 8.x we're talking about, are there : >> really that many consumers of SLIP to warrant it being carried forward at : >> all? : > : > It's kind of a basic. [C]SLIP has been historically handy to have around for : > situations which warrant it. Mind you, given that we have had tun(4) in the : > tree for years now, a userland implementation of SLIP is possible. : > : > As with all of these things it's down to someone sitting down and doing it. : > : > I'm not volunteering to support any of this as I don't use it myself (got : > enough on my plate), merely pointing out that support for SLIP in a system : > is something many people have taken for granted over the years, and for : > prototyping something or providing IP over a simple serial link without the : > configuration overhead of PPP, SLIP is something someone might be using. : > : > P.S. ahc(4) is commodity hardware, I think it can stay right where it is : > thank-you. : : My suspicion is that getting SLIP basically working in userspace is fairly : straight forward, SLiRP and friends have been doing this for years. I made my living for about a year working on TIA, which was a portable, userland implementation of PPP and SLIP/CSLIP. This was in about 1995 or so. It isn't that hard... : SLIP has its subtleties, but the current implementation is relatively : straight-forward, well-documented, etc. Yes, especially CSLIP. But frankly, they are a whole lot easier than PPP to get up and going... Warner From owner-freebsd-arch@FreeBSD.ORG Sun Jun 1 18:34:44 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA5FA106566C; Sun, 1 Jun 2008 18:34:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9BCAE8FC0C; Sun, 1 Jun 2008 18:34:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m51IWDPD032548; Sun, 1 Jun 2008 12:32:13 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 01 Jun 2008 12:33:51 -0600 (MDT) Message-Id: <20080601.123351.-950433793.imp@bsdimp.com> To: bms@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <483C2666.7010608@FreeBSD.org> References: <45633.1211870269@critter.freebsd.dk> <20080527064253.GG64397@hoeg.nl> <483C2666.7010608@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ed@80386.nl, current@FreeBSD.org, arch@FreeBSD.org, phk@phk.freebsd.dk, rwatson@FreeBSD.org, ade@FreeBSD.org, net@FreeBSD.org Subject: Re: HEAD UP: non-MPSAFE network drivers to be disabled X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2008 18:34:45 -0000 In message: <483C2666.7010608@FreeBSD.org> "Bruce M. Simpson" writes: : Other than that, line disciplines can go away. In the past I've uesd line disciplines to implement a keyboard driver for the Apple Newton Keyboard (serial protocol) so I could use it at any point after the loader (the system didn't run X11, so I couldn't use the X11 driver I wrote there). This system has been retired, and I don't think I ever forward ported them past about 3.mumble, if even that far. This code is badly decayed, and I have no requirement that it continues to work. But I know similar techniques are used in some embedded systems. Expect some delayed complaining if they go away entirely. But that may be OK given we're ridding tty of Giant. Now, if we could only sort out the syscons/keyboard/mouse mess... Warner From owner-freebsd-arch@FreeBSD.ORG Sun Jun 1 21:01:24 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D898B106567D; Sun, 1 Jun 2008 21:01:24 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 868EE8FC16; Sun, 1 Jun 2008 21:01:24 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 8DE77170E3; Sun, 1 Jun 2008 21:01:22 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m51L1KOg002205; Sun, 1 Jun 2008 21:01:21 GMT (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 01 Jun 2008 12:33:51 CST." <20080601.123351.-950433793.imp@bsdimp.com> Date: Sun, 01 Jun 2008 21:01:20 +0000 Message-ID: <2204.1212354080@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: ed@80386.nl, current@FreeBSD.org, arch@FreeBSD.org, rwatson@FreeBSD.org, ade@FreeBSD.org, net@FreeBSD.org, bms@FreeBSD.org Subject: Re: HEAD UP: non-MPSAFE network drivers to be disabled X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2008 21:01:25 -0000 In message <20080601.123351.-950433793.imp@bsdimp.com>, "M. Warner Losh" writes : >In the past I've uesd line disciplines to implement a keyboard driver >for the Apple Newton Keyboard (serial protocol) [...] But shouldn't you have used uart(4) for that ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sun Jun 1 21:58:01 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19FF01065674 for ; Sun, 1 Jun 2008 21:58:01 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id C2FCB8FC20 for ; Sun, 1 Jun 2008 21:58:00 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 9AB6E1CD58; Sun, 1 Jun 2008 23:57:59 +0200 (CEST) Date: Sun, 1 Jun 2008 23:57:59 +0200 From: Ed Schouten To: Julian Elischer Message-ID: <20080601215759.GN64397@hoeg.nl> References: <483EE7D5.5050408@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JjsO4Ft8DCMnlCnY" Content-Disposition: inline In-Reply-To: <483EE7D5.5050408@elischer.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: arch@freebsd.org Subject: Re: all mutexes -> read-write locks? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2008 21:58:01 -0000 --JjsO4Ft8DCMnlCnY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Julian, * Julian Elischer wrote: > it has been mentioned several times that through the evolution of the > locking primitives it has come to be that mutexes and exclusively =20 > acquired reader-writer locks are almost the same in terms of overhead > and that it might be a good move to define all mutexes to be > actually just that. > > this would allow people to slowly go through the system, catching low > hanging fruit by converting some of the mutex operations to reader > acquisitions wherever a writer is not required, thus reducing general =20 > system contention. > > Is there any thought on this? Last I heard jhb had confirmed that it > was feasible.. If this is going to be done, could we have mtx_* macro's pointing to the proper read/write ops? I know, it's just names, but I think most novice FreeBSD kernel hackers will almost instantaneously figure out what 'mtx' stands for. Why not make read/write locking a fundamental part of 'mtx' itself, if it doesn't introduce much overhead? --=20 Ed Schouten WWW: http://80386.nl/ --JjsO4Ft8DCMnlCnY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkhDG2cACgkQ52SDGA2eCwUz2gCdHhsGROTLMI2oy36oYY0279QY 5OYAn1CCk4Zu//F6gCqWSlRQswz56w+E =gmMW -----END PGP SIGNATURE----- --JjsO4Ft8DCMnlCnY-- From owner-freebsd-arch@FreeBSD.ORG Mon Jun 2 05:09:31 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 899EE106567F for ; Mon, 2 Jun 2008 05:09:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 62AD78FC18 for ; Mon, 2 Jun 2008 05:09:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 1CE21248B; Sun, 1 Jun 2008 22:09:31 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id C9D412D6017; Sun, 1 Jun 2008 22:09:30 -0700 (PDT) Message-ID: <4843808A.2060501@elischer.org> Date: Sun, 01 Jun 2008 22:09:30 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Daniel Eischen References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ed Schouten , arch@freebsd.org Subject: Re: all mutexes -> read-write locks? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 05:09:31 -0000 Daniel Eischen wrote: > On Sun, 1 Jun 2008, Ed Schouten wrote: > >> Hello Julian, >> >> * Julian Elischer wrote: >>> it has been mentioned several times that through the evolution of the >>> locking primitives it has come to be that mutexes and exclusively >>> acquired reader-writer locks are almost the same in terms of overhead >>> and that it might be a good move to define all mutexes to be >>> actually just that. >>> >>> this would allow people to slowly go through the system, catching low >>> hanging fruit by converting some of the mutex operations to reader >>> acquisitions wherever a writer is not required, thus reducing general >>> system contention. >>> >>> Is there any thought on this? Last I heard jhb had confirmed that it >>> was feasible.. >> >> If this is going to be done, could we have mtx_* macro's pointing to the >> proper read/write ops? I know, it's just names, but I think most novice >> FreeBSD kernel hackers will almost instantaneously figure out what 'mtx' >> stands for. > > Yes, mutex (mtx) is known very well. > > I don't think changing all mutex operations to rdlock operations > is wise. They are two different animals, regardless of their > implementation. Mutexes are very commonly used in device drivers, > at least outside of FreeBSD. And just because our current > implementation of them are the same as rwlocks doesn't mean that > it will always be the same in the future. > so let's imagine that mutexes dissappear... :-) From owner-freebsd-arch@FreeBSD.ORG Mon Jun 2 05:20:24 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA18C1065674 for ; Mon, 2 Jun 2008 05:20:24 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0268FC1B for ; Mon, 2 Jun 2008 05:20:23 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m525129o002653; Mon, 2 Jun 2008 01:01:02 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Mon, 02 Jun 2008 01:01:02 -0400 (EDT) Date: Mon, 2 Jun 2008 01:01:02 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Ed Schouten In-Reply-To: <20080601215759.GN64397@hoeg.nl> Message-ID: References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Julian Elischer Subject: Re: all mutexes -> read-write locks? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 05:20:24 -0000 On Sun, 1 Jun 2008, Ed Schouten wrote: > Hello Julian, > > * Julian Elischer wrote: >> it has been mentioned several times that through the evolution of the >> locking primitives it has come to be that mutexes and exclusively >> acquired reader-writer locks are almost the same in terms of overhead >> and that it might be a good move to define all mutexes to be >> actually just that. >> >> this would allow people to slowly go through the system, catching low >> hanging fruit by converting some of the mutex operations to reader >> acquisitions wherever a writer is not required, thus reducing general >> system contention. >> >> Is there any thought on this? Last I heard jhb had confirmed that it >> was feasible.. > > If this is going to be done, could we have mtx_* macro's pointing to the > proper read/write ops? I know, it's just names, but I think most novice > FreeBSD kernel hackers will almost instantaneously figure out what 'mtx' > stands for. Yes, mutex (mtx) is known very well. I don't think changing all mutex operations to rdlock operations is wise. They are two different animals, regardless of their implementation. Mutexes are very commonly used in device drivers, at least outside of FreeBSD. And just because our current implementation of them are the same as rwlocks doesn't mean that it will always be the same in the future. -- DE From owner-freebsd-arch@FreeBSD.ORG Mon Jun 2 05:27:57 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07AA11065676 for ; Mon, 2 Jun 2008 05:27:57 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 91E578FC12 for ; Mon, 2 Jun 2008 05:27:56 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m525RabW009486; Mon, 2 Jun 2008 01:27:36 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Mon, 02 Jun 2008 01:27:36 -0400 (EDT) Date: Mon, 2 Jun 2008 01:27:36 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <4843808A.2060501@elischer.org> Message-ID: References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> <4843808A.2060501@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , arch@freebsd.org Subject: Re: all mutexes -> read-write locks? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 05:27:57 -0000 On Sun, 1 Jun 2008, Julian Elischer wrote: > Daniel Eischen wrote: >> On Sun, 1 Jun 2008, Ed Schouten wrote: >> >>> Hello Julian, >>> >>> * Julian Elischer wrote: >>>> it has been mentioned several times that through the evolution of the >>>> locking primitives it has come to be that mutexes and exclusively >>>> acquired reader-writer locks are almost the same in terms of overhead >>>> and that it might be a good move to define all mutexes to be >>>> actually just that. >>>> >>>> this would allow people to slowly go through the system, catching low >>>> hanging fruit by converting some of the mutex operations to reader >>>> acquisitions wherever a writer is not required, thus reducing general >>>> system contention. >>>> >>>> Is there any thought on this? Last I heard jhb had confirmed that it >>>> was feasible.. >>> >>> If this is going to be done, could we have mtx_* macro's pointing to the >>> proper read/write ops? I know, it's just names, but I think most novice >>> FreeBSD kernel hackers will almost instantaneously figure out what 'mtx' >>> stands for. >> >> Yes, mutex (mtx) is known very well. >> >> I don't think changing all mutex operations to rdlock operations >> is wise. They are two different animals, regardless of their >> implementation. Mutexes are very commonly used in device drivers, >> at least outside of FreeBSD. And just because our current >> implementation of them are the same as rwlocks doesn't mean that >> it will always be the same in the future. >> > > so let's imagine that mutexes dissappear... > :-) I'd rather not. What do you have against them? Their API is simple enough to use. If there is code that really wants to have multiple readers, by all means change it to use rwlocks. Take a look at Solaris kernel mutexes and see how you can init a mutex that is to be used in an interrupt handler. -- DE From owner-freebsd-arch@FreeBSD.ORG Mon Jun 2 07:11:03 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 574361065678 for ; Mon, 2 Jun 2008 07:11:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outh.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 30FC38FC19 for ; Mon, 2 Jun 2008 07:11:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 0E1F422FA; Mon, 2 Jun 2008 00:11:03 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id BAD6D2D6011; Mon, 2 Jun 2008 00:11:02 -0700 (PDT) Message-ID: <48439D06.6020408@elischer.org> Date: Mon, 02 Jun 2008 00:11:02 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Daniel Eischen References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> <4843808A.2060501@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ed Schouten , arch@freebsd.org Subject: Re: all mutexes -> read-write locks? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 07:11:03 -0000 Daniel Eischen wrote: > On Sun, 1 Jun 2008, Julian Elischer wrote: > >> Daniel Eischen wrote: >>> On Sun, 1 Jun 2008, Ed Schouten wrote: >>> >>>> Hello Julian, >>>> >>>> * Julian Elischer wrote: >>>>> it has been mentioned several times that through the evolution of the >>>>> locking primitives it has come to be that mutexes and exclusively >>>>> acquired reader-writer locks are almost the same in terms of overhead >>>>> and that it might be a good move to define all mutexes to be >>>>> actually just that. >>>>> >>>>> this would allow people to slowly go through the system, catching low >>>>> hanging fruit by converting some of the mutex operations to reader >>>>> acquisitions wherever a writer is not required, thus reducing general >>>>> system contention. >>>>> >>>>> Is there any thought on this? Last I heard jhb had confirmed that it >>>>> was feasible.. >>>> >>>> If this is going to be done, could we have mtx_* macro's pointing to >>>> the >>>> proper read/write ops? I know, it's just names, but I think most novice >>>> FreeBSD kernel hackers will almost instantaneously figure out what >>>> 'mtx' >>>> stands for. >>> >>> Yes, mutex (mtx) is known very well. >>> >>> I don't think changing all mutex operations to rdlock operations >>> is wise. They are two different animals, regardless of their >>> implementation. Mutexes are very commonly used in device drivers, >>> at least outside of FreeBSD. And just because our current >>> implementation of them are the same as rwlocks doesn't mean that >>> it will always be the same in the future. >>> >> >> so let's imagine that mutexes dissappear... >> :-) > > I'd rather not. What do you have against them? People use them without thinking about whether they need to be so strict. > Their API is simple > enough to use. If there is code that really wants to have multiple > readers, by all means change it to use rwlocks. yes but we have a lot of code that uses mutexes.. changing it would allow a slow transition to using rw locks. > > Take a look at Solaris kernel mutexes and see how you can init > a mutex that is to be used in an interrupt handler. how does that help making more things use read locking? > From owner-freebsd-arch@FreeBSD.ORG Mon Jun 2 11:06:45 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD6F61065681 for ; Mon, 2 Jun 2008 11:06:45 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B98A98FC2B for ; Mon, 2 Jun 2008 11:06:45 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m52B6j02093103 for ; Mon, 2 Jun 2008 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m52B6j3u093099 for freebsd-arch@FreeBSD.org; Mon, 2 Jun 2008 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Jun 2008 11:06:45 GMT Message-Id: <200806021106.m52B6j3u093099@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 11:06:45 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 2 15:38:17 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF4731065677 for ; Mon, 2 Jun 2008 15:38:17 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id D22218FC22 for ; Mon, 2 Jun 2008 15:38:17 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m52FbdEa009879; Mon, 2 Jun 2008 08:37:56 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m52FYsiX093207; Mon, 2 Jun 2008 08:34:56 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (hudson-trading.com [66.150.84.160] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m52FYrtX082447; Mon, 2 Jun 2008 08:34:53 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Mon, 02 Jun 2008 11:34:53 -0400 Message-ID: From: "George V. Neville-Neil" To: Julian Elischer In-Reply-To: <48439D06.6020408@elischer.org> References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> <4843808A.2060501@elischer.org> <48439D06.6020408@elischer.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1.50 (i386-apple-darwin8.11.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.00 () [Tag at 5.00] X-CanItPRO-Stream: default X-Canit-Stats-ID: 543825 - 743419b95ec6 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: arch@freebsd.org, Ed Schouten Subject: Re: all mutexes -> read-write locks? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 15:38:18 -0000 At Mon, 02 Jun 2008 00:11:02 -0700, julian wrote: > > Daniel Eischen wrote: > > I'd rather not. What do you have against them? > > People use them without thinking about whether they need to be so > strict. This is an age old problem that removing mutexes will never fix. We could add documentation to the manual pages though saying, "Do you really really need this?" > > Their API is simple enough to use. If there is code that really > > wants to have multiple readers, by all means change it to use > > rwlocks. > > > yes but we have a lot of code that uses mutexes.. changing it would > allow a slow transition to using rw locks. We will likely have to do that ourselves. Sorry, but this is a Sisyphean task, and removing mutexes will not prevent the rock from falling back upon us again. Best, George From owner-freebsd-arch@FreeBSD.ORG Mon Jun 2 17:14:30 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBF961065671 for ; Mon, 2 Jun 2008 17:14:29 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id A70168FC20 for ; Mon, 2 Jun 2008 17:14:29 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m52HEAFJ009079; Mon, 2 Jun 2008 13:14:10 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Mon, 02 Jun 2008 13:14:10 -0400 (EDT) Date: Mon, 2 Jun 2008 13:14:10 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <48439D06.6020408@elischer.org> Message-ID: References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> <4843808A.2060501@elischer.org> <48439D06.6020408@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , arch@freebsd.org Subject: Re: all mutexes -> read-write locks? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 17:14:30 -0000 On Mon, 2 Jun 2008, Julian Elischer wrote: > Daniel Eischen wrote: >> On Sun, 1 Jun 2008, Julian Elischer wrote: >> >>> Daniel Eischen wrote: >>>> On Sun, 1 Jun 2008, Ed Schouten wrote: >>>> >>>>> Hello Julian, >>>>> >>>>> * Julian Elischer wrote: >>>>>> it has been mentioned several times that through the evolution of the >>>>>> locking primitives it has come to be that mutexes and exclusively >>>>>> acquired reader-writer locks are almost the same in terms of overhead >>>>>> and that it might be a good move to define all mutexes to be >>>>>> actually just that. >>>>>> >>>>>> this would allow people to slowly go through the system, catching low >>>>>> hanging fruit by converting some of the mutex operations to reader >>>>>> acquisitions wherever a writer is not required, thus reducing general >>>>>> system contention. >>>>>> >>>>>> Is there any thought on this? Last I heard jhb had confirmed that it >>>>>> was feasible.. >>>>> >>>>> If this is going to be done, could we have mtx_* macro's pointing to the >>>>> proper read/write ops? I know, it's just names, but I think most novice >>>>> FreeBSD kernel hackers will almost instantaneously figure out what 'mtx' >>>>> stands for. >>>> >>>> Yes, mutex (mtx) is known very well. >>>> >>>> I don't think changing all mutex operations to rdlock operations >>>> is wise. They are two different animals, regardless of their >>>> implementation. Mutexes are very commonly used in device drivers, >>>> at least outside of FreeBSD. And just because our current >>>> implementation of them are the same as rwlocks doesn't mean that >>>> it will always be the same in the future. >>>> >>> >>> so let's imagine that mutexes dissappear... >>> :-) >> >> I'd rather not. What do you have against them? > > People use them without thinking about whether they need to be so > strict. > >> Their API is simple >> enough to use. If there is code that really wants to have multiple >> readers, by all means change it to use rwlocks. > > > yes but we have a lot of code that uses mutexes.. changing it would allow a > slow transition to using rw locks. > >> >> Take a look at Solaris kernel mutexes and see how you can init >> a mutex that is to be used in an interrupt handler. > > how does that help making more things use read locking? It doesn't, it shows one reason why mutexes can be different than read/write locks. I don't see how most low-level leaf drivers can make use of read/write locks. All they want to do is prevent simultaneous access to a device and setup I/O operations. By keeping the mutex and rwlock APIs separate regardless of their implementation, you allow the code to specify what kind of locking it wants. If you convert all mutexes to rwlocks you lose this information and it makes it harder to go back again. On the other hand, if you s/mtx_foo/rw_foo/, you still have to analyze the code to tell whether or not you can truly turn them into simultaneous read locks. So what is the harm in analyzing the code first, and then converting it to rwlocks IFF it can make use of it? -- DE From owner-freebsd-arch@FreeBSD.ORG Mon Jun 2 17:34:41 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 020EA1065670 for ; Mon, 2 Jun 2008 17:34:41 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id CC9618FC25 for ; Mon, 2 Jun 2008 17:34:40 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id C90EE170E3; Mon, 2 Jun 2008 17:34:38 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m52HYb29006572; Mon, 2 Jun 2008 17:34:37 GMT (envelope-from phk@critter.freebsd.dk) To: Daniel Eischen From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 02 Jun 2008 13:14:10 -0400." Date: Mon, 02 Jun 2008 17:34:37 +0000 Message-ID: <6571.1212428077@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Ed Schouten , Julian Elischer , arch@freebsd.org Subject: Re: all mutexes -> read-write locks? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 17:34:41 -0000 In message , Daniel Eischen wri tes: >It doesn't, it shows one reason why mutexes can be different >than read/write locks. Agreed. There is no easy way to determine which mutexes can be rw_locks, so take the correct route: education. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 2 17:35:38 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38A5B106567A for ; Mon, 2 Jun 2008 17:35:38 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 374CD8FC17 for ; Mon, 2 Jun 2008 17:35:38 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 13C821A4D81; Mon, 2 Jun 2008 10:19:46 -0700 (PDT) Date: Mon, 2 Jun 2008 10:19:46 -0700 From: Alfred Perlstein To: Daniel Eischen Message-ID: <20080602171946.GJ48790@elvis.mu.org> References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> <4843808A.2060501@elischer.org> <48439D06.6020408@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Ed Schouten , Julian Elischer , arch@freebsd.org Subject: Re: all mutexes -> read-write locks? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 17:35:38 -0000 * Daniel Eischen [080602 10:14] wrote: > On Mon, 2 Jun 2008, Julian Elischer wrote: > > > >how does that help making more things use read locking? > > It doesn't, it shows one reason why mutexes can be different > than read/write locks. > > I don't see how most low-level leaf drivers can make use of > read/write locks. All they want to do is prevent simultaneous > access to a device and setup I/O operations. > > By keeping the mutex and rwlock APIs separate regardless of > their implementation, you allow the code to specify what kind > of locking it wants. If you convert all mutexes to rwlocks > you lose this information and it makes it harder to go back > again. On the other hand, if you s/mtx_foo/rw_foo/, you still > have to analyze the code to tell whether or not you can > truly turn them into simultaneous read locks. So what is > the harm in analyzing the code first, and then converting > it to rwlocks IFF it can make use of it? I agree with Daniel here. I also think the following points are relevant: 1) we don't need to rototil the code to s/mtx/rw/ right now. 2) rw locks may not be as effecient as mtx later on and there's no point in doing it right now. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Sat Jun 7 00:19:26 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D83D21065678 for ; Sat, 7 Jun 2008 00:19:26 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.71]) by mx1.freebsd.org (Postfix) with ESMTP id BAF398FC0C for ; Sat, 7 Jun 2008 00:19:26 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtp016-bge351000 (asmtp016-bge351000 [10.150.69.79]) by smtpoutm.mac.com (Xserve/smtpout008/MantshX 4.0) with ESMTP id m570JQSU006990 for ; Fri, 6 Jun 2008 17:19:26 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from [192.168.1.102] (209-128-86-226.BAYAREA.NET [209.128.86.226]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K2200HD9GWDM3D2@asmtp016.mac.com> for arch@freebsd.org; Fri, 06 Jun 2008 17:19:26 -0700 (PDT) Message-id: <863BF908-3441-4CEE-8DA0-375965417573@mac.com> From: Marcel Moolenaar To: arch@freebsd.org Date: Fri, 06 Jun 2008 17:19:25 -0700 X-Mailer: Apple Mail (2.924) Cc: Subject: gpt(8) will be removed soon X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2008 00:19:26 -0000 All, As previously mentioned, gpt(8) is obsoleted by gpart(8). I'll be removing gpt(8) soon. If you know of a reason not to remove gpt(8), let me know. FYI, -- Marcel Moolenaar xcllnt@mac.com