From owner-freebsd-smp Sun Dec 10 20:40:42 2000 From owner-freebsd-smp@FreeBSD.ORG Sun Dec 10 20:40:39 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 22D3C37B400; Sun, 10 Dec 2000 20:40:38 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 189776AB69; Mon, 11 Dec 2000 15:10:35 +1030 (CST) Date: Mon, 11 Dec 2000 15:10:35 +1030 From: Greg Lehey To: FreeBSD SMP list , FreeBSD mobile Mailing List Subject: Anybody using PCMCIA cards on an SMP box? Message-ID: <20001211151034.L69363@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm currently testing some PCMCIA stuff on my test box, which happens to be -CURRENT SMP. I'm getting some strange, non-reproducible problems, and it occurs to me that maybe the PCMCIA code has never been tested on SMP. If anybody has done this before, please let me know. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Dec 10 21:32:21 2000 From owner-freebsd-smp@FreeBSD.ORG Sun Dec 10 21:32:18 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C328737B400; Sun, 10 Dec 2000 21:32:13 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eBB5WCs66460; Sun, 10 Dec 2000 22:32:12 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id WAA33825; Sun, 10 Dec 2000 22:32:12 -0700 (MST) Message-Id: <200012110532.WAA33825@harmony.village.org> To: Greg Lehey Subject: Re: Anybody using PCMCIA cards on an SMP box? Cc: FreeBSD SMP list , FreeBSD mobile Mailing List In-reply-to: Your message of "Mon, 11 Dec 2000 15:10:35 +1030." <20001211151034.L69363@wantadilla.lemis.com> References: <20001211151034.L69363@wantadilla.lemis.com> Date: Sun, 10 Dec 2000 22:32:12 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <20001211151034.L69363@wantadilla.lemis.com> Greg Lehey writes: : I'm currently testing some PCMCIA stuff on my test box, which happens : to be -CURRENT SMP. I'm getting some strange, non-reproducible : problems, and it occurs to me that maybe the PCMCIA code has never : been tested on SMP. If anybody has done this before, please let me : know. I have not had success getting pcmcia working on our SMP boxes are work for reasons unknown. Every time I go to look at the reasons, another crisis comes up that keeps from poking at it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 11 4:41:50 2000 From owner-freebsd-smp@FreeBSD.ORG Mon Dec 11 04:41:49 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 4E52437B400 for ; Mon, 11 Dec 2000 04:41:48 -0800 (PST) Received: (qmail 31259 invoked by uid 0); 11 Dec 2000 12:41:45 -0000 Received: from p3e9e206d.dip.t-dialin.net (HELO 1xp133) (62.158.32.109) by mail.gmx.net (mail08) with SMTP; 11 Dec 2000 12:41:45 -0000 Message-ID: <005101c0636f$ded4edb0$0400a8c0@1xp133> From: "Gregor Bittel" To: Subject: Website - SMP updated? Date: Mon, 11 Dec 2000 13:42:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, (1st: sorry for my bad english). Jason Evans told me, that you wrote the Site: http://people.freebsd.org/~fsmp/SMP/hardware.html . I have now decided to update this list. (Because I want to buy an new SMP-Board next Year, but many Boards do not yet work under FreeBSD. (I´ve probed the Supermicro-P3DR3, without success on 4.1-Release). So I want to write a new List with all SMP-Boards, who are working under FreeBSD - even updatet with the newest Boards and informations, and how to make it run. Now also the question to you: Can I do this? -Gregor. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 11 4:55:47 2000 From owner-freebsd-smp@FreeBSD.ORG Mon Dec 11 04:55:45 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 3D04437B400 for ; Mon, 11 Dec 2000 04:55:45 -0800 (PST) Received: (qmail 15206 invoked by uid 0); 11 Dec 2000 12:55:43 -0000 Received: from p3e9e206d.dip.t-dialin.net (HELO 1xp133) (62.158.32.109) by mail.gmx.net (mail03) with SMTP; 11 Dec 2000 12:55:43 -0000 Message-ID: <005801c06371$d27bb1f0$0400a8c0@1xp133> From: "Gregor Bittel" To: Subject: Re: Website - SMP updated? Date: Mon, 11 Dec 2000 13:54:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org sri, this Mailing should be posted to Steve Passe, has somebody his eMail-Adress? -Gregor. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 11 7:48:44 2000 From owner-freebsd-smp@FreeBSD.ORG Mon Dec 11 07:48:40 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by hub.freebsd.org (Postfix) with ESMTP id A9BCD37B400 for ; Mon, 11 Dec 2000 07:48:39 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA19232; Mon, 11 Dec 2000 07:48:38 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eBBFmS619772; Mon, 11 Dec 2000 07:48:28 -0800 X-Virus-Scanned: Mon, 11 Dec 2000 07:48:28 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from brakescr.iprg.nokia.com (205.226.1.186, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpd2XRk8Y; Mon, 11 Dec 2000 07:41:38 PST Sender: michaelw@IPRG.nokia.com Message-ID: <3A34F5B4.10A27571@iprg.nokia.com> Date: Mon, 11 Dec 2000 07:41:41 -0800 From: Michael Glenn Williams Organization: NOKIA X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Arun Sharma Cc: Chuck Paterson , smp@FreeBSD.ORG Subject: Re: Userland atomic assignments References: <200012091602.eB9G2UH06249@berserker.bsdi.com> <3A318757.4040108@sharmas.dhs.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org There are also sometimes issues if the assignment is to code. The interaction of the caches and the memory model in force can be hard to keep clear. Userland sharing memory locations between threads (same address space & cache footprint) or processes (shmem/mmap type stuff) have things like pagefaults of course, but won't fetch something partially written from memory. Even if an I/O device is updating the memory location this has to be preserved. Even if the architecture permits wierd alignments of "atomic sized writes" it has to enforce this. Moving to a relaxed memory model has been difficult because all the ABI and DDI/DKI type issues of coordination and backwards compatibility get in the way. If a new processor architecture came about that had reason to support SMP designs and no legacy drivers or application binaries, they could do an RMO. Mike Arun Sharma wrote: > Chuck Paterson wrote: > > > } > > }However, the complexity comes from memory ordering issues. All of x86 boxes > > }ensure sequential consistency. > > } > > > > Sequenctial consistency from a single processor, which may well > > be what you meant. > > Actually, what I wrote in my previous mail wasn't completely accurate > about sequential > consistency. (c == d) => (a == b) basically means writes happen in program > order as you say above. > > > Writes from different processors to different cache lines are not > > ordered with respect to one another. Also writes from one processor > > are not at all ordered with respect to reads from another processor. > > > > What is guaranteed is that writes from a single processor will be > > ordered with respect to one another as viewed from any processor. > > What sequential consistency guarantees is that writes as seen from > some other processor would make sense for _some_ arbitrary intermixing > of writes from other processors. > > A more formal definition: > > http://whatis.techtarget.com/WhatIs_Definition_Page/0,4152,212962,00.html > -Arun > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 11 16:50:41 2000 From owner-freebsd-smp@FreeBSD.ORG Mon Dec 11 16:50:39 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id A285737B402 for ; Mon, 11 Dec 2000 16:50:39 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 13F602B2AA; Mon, 11 Dec 2000 18:50:39 -0600 (CST) Date: Mon, 11 Dec 2000 18:50:38 -0600 From: Bill Fumerola To: Gregor Bittel Cc: smp@FreeBSD.org Subject: Re: Website - SMP updated? Message-ID: <20001211185038.W86825@elvis.mu.org> References: <005101c0636f$ded4edb0$0400a8c0@1xp133> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <005101c0636f$ded4edb0$0400a8c0@1xp133>; from Gregor.Bittel@GMX.de on Mon, Dec 11, 2000 at 01:42:12PM +0100 X-Operating-System: FreeBSD 4.2-FEARSOME-20001103 i386 Sender: billf@elvis.mu.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Dec 11, 2000 at 01:42:12PM +0100, Gregor Bittel wrote: > Hi, > (1st: sorry for my bad english). > Jason Evans told me, that you wrote the Site: > http://people.freebsd.org/~fsmp/SMP/hardware.html people.freebsd.org/~foo ==> foo@freebsd.org you wanted 'fsmp@freebsd.org'. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 11 20:10: 6 2000 From owner-freebsd-smp@FreeBSD.ORG Mon Dec 11 20:10:01 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id EE25537B400; Mon, 11 Dec 2000 20:10:00 -0800 (PST) Received: by peorth.iteration.net (Postfix, from userid 1001) id 2063E57431; Mon, 11 Dec 2000 22:10:11 -0600 (CST) Date: Mon, 11 Dec 2000 22:10:11 -0600 From: "Michael C . Wu" To: Greg Lehey Cc: FreeBSD SMP list , FreeBSD mobile Mailing List Subject: Re: Anybody using PCMCIA cards on an SMP box? Message-ID: <20001211221010.A89527@peorth.iteration.net> Reply-To: "Michael C . Wu" Mail-Followup-To: "Michael C . Wu" , Greg Lehey , FreeBSD SMP list , FreeBSD mobile Mailing List References: <20001211151034.L69363@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001211151034.L69363@wantadilla.lemis.com>; from grog@lemis.com on Mon, Dec 11, 2000 at 03:10:35PM +1030 X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: keichii@peorth.iteration.net Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Dec 11, 2000 at 03:10:35PM +1030, Greg Lehey scribbled: | I'm currently testing some PCMCIA stuff on my test box, which happens | to be -CURRENT SMP. I'm getting some strange, non-reproducible | problems, and it occurs to me that maybe the PCMCIA code has never | been tested on SMP. If anybody has done this before, please let me | know. I have the Lucent ISA card and Orinoco Gold card working on 4.2-BETA. (I know it should be updated, but have not had the time to.) For a couple days, this box ran -CURRENT SMPNG fine with the pcmcia+wavelan working. It was 2000102x-CURRENT. However, if I enable the SMPNG code with PCMCIA, it does not stay up longer than 5 hours. This is an Abit BP6 box, one that I think is the same as your box. -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 11 20:17:56 2000 From owner-freebsd-smp@FreeBSD.ORG Mon Dec 11 20:17:52 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id A87AC37B400; Mon, 11 Dec 2000 20:17:47 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id A1C446AB68; Tue, 12 Dec 2000 14:47:44 +1030 (CST) Date: Tue, 12 Dec 2000 14:47:44 +1030 From: Greg Lehey To: "Michael C . Wu" , FreeBSD SMP list , FreeBSD mobile Mailing List Subject: Re: Anybody using PCMCIA cards on an SMP box? Message-ID: <20001212144744.K76343@wantadilla.lemis.com> References: <20001211151034.L69363@wantadilla.lemis.com> <20001211221010.A89527@peorth.iteration.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001211221010.A89527@peorth.iteration.net>; from keichii@iteration.net on Mon, Dec 11, 2000 at 10:10:11PM -0600 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Monday, 11 December 2000 at 22:10:11 -0600, Michael C . Wu wrote: > On Mon, Dec 11, 2000 at 03:10:35PM +1030, Greg Lehey scribbled: >> I'm currently testing some PCMCIA stuff on my test box, which happens >> to be -CURRENT SMP. I'm getting some strange, non-reproducible >> problems, and it occurs to me that maybe the PCMCIA code has never >> been tested on SMP. If anybody has done this before, please let me >> know. > > I have the Lucent ISA card and Orinoco Gold card working on 4.2-BETA. > (I know it should be updated, but have not had the time to.) > For a couple days, this box ran -CURRENT SMPNG fine with the > pcmcia+wavelan working. It was 2000102x-CURRENT. However, > if I enable the SMPNG code with PCMCIA, it does not stay up longer > than 5 hours. Ahh. That seems reasonable. Looks lie we have more debugging to do. > This is an Abit BP6 box, one that I think is the same as your box. Yes, that's correct. But I don't think it's related to the motherboard. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 11 20:31:33 2000 From owner-freebsd-smp@FreeBSD.ORG Mon Dec 11 20:31:28 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id 7ACE037B400; Mon, 11 Dec 2000 20:31:26 -0800 (PST) Received: by peorth.iteration.net (Postfix, from userid 1001) id 81AE757431; Mon, 11 Dec 2000 22:31:32 -0600 (CST) Date: Mon, 11 Dec 2000 22:31:32 -0600 From: "Michael C . Wu" To: Greg Lehey Cc: "Michael C . Wu" , FreeBSD SMP list , FreeBSD mobile Mailing List Subject: Re: Anybody using PCMCIA cards on an SMP box? Message-ID: <20001211223132.C89527@peorth.iteration.net> Reply-To: "Michael C . Wu" Mail-Followup-To: "Michael C . Wu" , Greg Lehey , FreeBSD SMP list , FreeBSD mobile Mailing List References: <20001211151034.L69363@wantadilla.lemis.com> <20001211221010.A89527@peorth.iteration.net> <20001212144744.K76343@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001212144744.K76343@wantadilla.lemis.com>; from grog@lemis.com on Tue, Dec 12, 2000 at 02:47:44PM +1030 X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: keichii@peorth.iteration.net Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Dec 12, 2000 at 02:47:44PM +1030, Greg Lehey scribbled: | On Monday, 11 December 2000 at 22:10:11 -0600, Michael C . Wu wrote: | > On Mon, Dec 11, 2000 at 03:10:35PM +1030, Greg Lehey scribbled: | >> I'm currently testing some PCMCIA stuff on my test box, which happens | >> to be -CURRENT SMP. I'm getting some strange, non-reproducible | >> problems, and it occurs to me that maybe the PCMCIA code has never | >> been tested on SMP. If anybody has done this before, please let me | >> know. | > | > I have the Lucent ISA card and Orinoco Gold card working on 4.2-BETA. | > (I know it should be updated, but have not had the time to.) | > For a couple days, this box ran -CURRENT SMPNG fine with the | > pcmcia+wavelan working. It was 2000102x-CURRENT. However, | > if I enable the SMPNG code with PCMCIA, it does not stay up longer | > than 5 hours. | | Ahh. That seems reasonable. Looks lie we have more debugging to do. I should mention that this box is now running under semi-heavy load 24/7 as my do-it-all server with SMP and oldcard in 4.2-BETA. (i.e. load average 2.x, disk constant output 200k/sec.) What happens when the box crashed in -CURRENT is that: 1. boot 2. running fine 3. Do anything useful that fork()'s 4. thousands of the same fork()'s spawns again and again in extraordinary speed. (I wrote a script that automatically runs Apache's "ad" http benchmark app. While the script runs, it sends "killall -9 httpd" as fast as /bin/sh can send it. The machine still dies, but lives only a few minutes longer.) 5. box dies due to heavy load, hard lock, not able to break to ddb/gdb, no response to anything. It ran fine with an UP kernel in 2000102x-CURRENT without the above problem. | > This is an Abit BP6 box, one that I think is the same as your box. | | Yes, that's correct. But I don't think it's related to the | motherboard. -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 11 22:42:43 2000 From owner-freebsd-smp@FreeBSD.ORG Mon Dec 11 22:42:39 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id 0242637B400; Mon, 11 Dec 2000 22:42:39 -0800 (PST) Received: by peorth.iteration.net (Postfix, from userid 1001) id C8C0F57434; Tue, 12 Dec 2000 00:42:49 -0600 (CST) Date: Tue, 12 Dec 2000 00:42:49 -0600 From: "Michael C . Wu" To: Greg Lehey Cc: FreeBSD SMP list , FreeBSD mobile Mailing List Subject: Re: Anybody using PCMCIA cards on an SMP box? Message-ID: <20001212004249.C91376@peorth.iteration.net> Reply-To: "Michael C . Wu" Mail-Followup-To: "Michael C . Wu" , Greg Lehey , FreeBSD SMP list , FreeBSD mobile Mailing List References: <20001211151034.L69363@wantadilla.lemis.com> <20001211221010.A89527@peorth.iteration.net> <20001212144744.K76343@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001212144744.K76343@wantadilla.lemis.com>; from grog@lemis.com on Tue, Dec 12, 2000 at 02:47:44PM +1030 X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: keichii@peorth.iteration.net Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Dec 12, 2000 at 02:47:44PM +1030, Greg Lehey scribbled: | On Monday, 11 December 2000 at 22:10:11 -0600, Michael C . Wu wrote: | > On Mon, Dec 11, 2000 at 03:10:35PM +1030, Greg Lehey scribbled: | >> I'm currently testing some PCMCIA stuff on my test box, which happens | >> to be -CURRENT SMP. I'm getting some strange, non-reproducible | >> problems, and it occurs to me that maybe the PCMCIA code has never | >> been tested on SMP. If anybody has done this before, please let me | >> know. | > | > I have the Lucent ISA card and Orinoco Gold card working on 4.2-BETA. | > (I know it should be updated, but have not had the time to.) | > For a couple days, this box ran -CURRENT SMPNG fine with the | > pcmcia+wavelan working. It was 2000102x-CURRENT. However, | > if I enable the SMPNG code with PCMCIA, it does not stay up longer | > than 5 hours. | | Ahh. That seems reasonable. Looks lie we have more debugging to do. One thing that just came to my mind, has anyone tested SMPNG with cardbus/newcard ? -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 11 23:58:42 2000 From owner-freebsd-smp@FreeBSD.ORG Mon Dec 11 23:58:39 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C96A737B400; Mon, 11 Dec 2000 23:58:37 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eBC7wZs72451; Tue, 12 Dec 2000 00:58:36 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA27835; Tue, 12 Dec 2000 00:58:35 -0700 (MST) Message-Id: <200012120758.AAA27835@harmony.village.org> To: "Michael C . Wu" Subject: Re: Anybody using PCMCIA cards on an SMP box? Cc: Greg Lehey , FreeBSD SMP list , FreeBSD mobile Mailing List In-reply-to: Your message of "Tue, 12 Dec 2000 00:42:49 CST." <20001212004249.C91376@peorth.iteration.net> References: <20001212004249.C91376@peorth.iteration.net> <20001211151034.L69363@wantadilla.lemis.com> <20001211221010.A89527@peorth.iteration.net> <20001212144744.K76343@wantadilla.lemis.com> Date: Tue, 12 Dec 2000 00:58:35 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <20001212004249.C91376@peorth.iteration.net> "Michael C . Wu" writes: : One thing that just came to my mind, has anyone tested SMPNG : with cardbus/newcard ? No. Not in an MP machine. The pci cardbus bridge cards that I have do not work with newcard and 16-bit pccards don't work yet. I'm sure some locking will need to happen, but I've not kept close tabs on what I need to do to do that over the last several months. Thankfully I have access to MP systems at work and there's a large desire on the part of my employer for that to work. That desire doesn't necessary translate to a lot of on-the-clock time for that task, but it is on my list of eventually projects. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Dec 12 2:15:35 2000 From owner-freebsd-smp@FreeBSD.ORG Tue Dec 12 02:15:32 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from correu.andorra.ad (unknown [194.158.78.13]) by hub.freebsd.org (Postfix) with ESMTP id 65AF637B402 for ; Tue, 12 Dec 2000 02:15:31 -0800 (PST) Received: from KR8DESKTOP ([194.158.75.4]) by correu.andorra.ad with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y316WSR0; Tue, 12 Dec 2000 11:15:28 +0100 Message-ID: <01af01c08393$e56e0dc0$b8adfea9@kr8desktop> From: "John Gold" To: "FreeBSD SMP list" Subject: supermicro 370DL3 Date: Sun, 21 Jan 2001 10:21:18 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AC_01C08393.E48C3940" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_01AC_01C08393.E48C3940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, has anybody successfully used the Supermicro 370DL3 dual processor board = under freebsd SMP? thanks, John ------=_NextPart_000_01AC_01C08393.E48C3940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
has anybody successfully used the Supermicro 370DL3 = dual=20 processor board under freebsd SMP?
 
thanks,
 
John
------=_NextPart_000_01AC_01C08393.E48C3940-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Dec 12 9: 8:49 2000 From owner-freebsd-smp@FreeBSD.ORG Tue Dec 12 09:08:45 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 7D1DE37B699; Tue, 12 Dec 2000 09:08:40 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBCH8XE88678; Tue, 12 Dec 2000 09:08:34 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001212004249.C91376@peorth.iteration.net> Date: Tue, 12 Dec 2000 09:08:38 -0800 (PST) From: John Baldwin To: "Michael C . Wu" Subject: Re: Anybody using PCMCIA cards on an SMP box? Cc: FreeBSD mobile Mailing List Cc: FreeBSD mobile Mailing List , FreeBSD SMP list , Greg Lehey Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 12-Dec-00 Michael C . Wu wrote: > On Tue, Dec 12, 2000 at 02:47:44PM +1030, Greg Lehey scribbled: >| On Monday, 11 December 2000 at 22:10:11 -0600, Michael C . Wu wrote: >| > On Mon, Dec 11, 2000 at 03:10:35PM +1030, Greg Lehey scribbled: >| >> I'm currently testing some PCMCIA stuff on my test box, which happens >| >> to be -CURRENT SMP. I'm getting some strange, non-reproducible >| >> problems, and it occurs to me that maybe the PCMCIA code has never >| >> been tested on SMP. If anybody has done this before, please let me >| >> know. >| > >| > I have the Lucent ISA card and Orinoco Gold card working on 4.2-BETA. >| > (I know it should be updated, but have not had the time to.) >| > For a couple days, this box ran -CURRENT SMPNG fine with the >| > pcmcia+wavelan working. It was 2000102x-CURRENT. However, >| > if I enable the SMPNG code with PCMCIA, it does not stay up longer >| > than 5 hours. >| >| Ahh. That seems reasonable. Looks lie we have more debugging to do. > > One thing that just came to my mind, has anyone tested SMPNG > with cardbus/newcard ? It has worked in the past. Right now inserting the only cardbus card I have (Linksys 10/100 ethernet adapter) hardlocks the machine with interrupts disabled sometime before or during dc_attach. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Dec 12 14:35:54 2000 From owner-freebsd-smp@FreeBSD.ORG Tue Dec 12 14:35:50 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from spock.org (cm-24-169-11-24.nycap.rr.com [24.169.11.24]) by hub.freebsd.org (Postfix) with ESMTP id 9368A37B6AC; Tue, 12 Dec 2000 14:35:46 -0800 (PST) Received: (from jon@localhost) by spock.org serial EF600Q3T-B7F; Tue, 12 Dec 2000 17:35:12 -0500 (EST) (envelope-from jon) Date: Tue, 12 Dec 2000 17:35:12 -0500 From: Jonathan Chen To: "Michael C . Wu" Cc: Greg Lehey , FreeBSD SMP list , FreeBSD mobile Mailing List Subject: Re: Anybody using PCMCIA cards on an SMP box? Message-ID: <20001212173512.A59184@spock.org> References: <20001211151034.L69363@wantadilla.lemis.com> <20001211221010.A89527@peorth.iteration.net> <20001212144744.K76343@wantadilla.lemis.com> <20001212004249.C91376@peorth.iteration.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: telnet/1.1x In-Reply-To: <20001212004249.C91376@peorth.iteration.net>; from keichii@iteration.net on Tue, Dec 12, 2000 at 12:42:49AM -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Dec 12, 2000 at 12:42:49AM -0600, Michael C . Wu wrote: > > One thing that just came to my mind, has anyone tested SMPNG > with cardbus/newcard ? I've been trying to do that. Unfortunately, my -CURRENT box with SMP doesn't like to stay up for more than 10 minutes. I'll be poking around some more over the next month... -- (o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o) \\\_\ Jonathan Chen jon@spock.org /_/// <____) No electrons were harmed during production of this message (____> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Dec 14 7:17:33 2000 From owner-freebsd-smp@FreeBSD.ORG Thu Dec 14 07:17:28 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 9D4D437B402 for ; Thu, 14 Dec 2000 07:17:23 -0800 (PST) Received: from victoria-210.budapest.interware.hu ([195.70.63.210] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 146a7q-0006KM-00 for ; Thu, 14 Dec 2000 16:16:54 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A38E440.B89DA298@elischer.org> Date: Thu, 14 Dec 2000 07:16:16 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: smp@freebsd.org Subject: Mutex roadmap Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In my attempts to understand locking on behaplf of netgraph, I ended up writing up this little roadmap of where things are... In the hope that SOMEONE finds it useful, I'm posting it here. ====== Start Roadmap ======= Basic roadmap to Mutex sources in FreeBSD. What is where, what it calls and where to find that.. ====================================================================== mutex structure: (mtx) defined in sys/mutex.h extended with an external structure (mtx_debug) when WITNESS defined. =========== BASIC calls used in the kernel by programmers =============== mtx_enter() is a MACRO that wraps _mtx_enter() with __LINE__ and __FILE__ info. defined in sys/mutex.h mtx_exit() is a MACRO that wraps _mtx_exit() with __LINE__ and __FILE__ info. defined in sys/mutex.h ============= Actual calls after cpp (Not used by programmer directly)==== _mutex_enter() An inline finction that is defined in sys/mutex.h Also compiled into an actual function in kern/mutex.c by including the inlines but removing the word "__inline" The inline version usually knows the constant values of the 'type' argument when expanded and can therefore optimise away all code branches that are not required. Usually this is almost all of the function. It uses the following primatives: disable_intr() _getlock_norecurse() _getlock_spin_block() _getlock_sleep() As well as possibly WITNESS_ENTER() if it is defined. _mutex_exit() An inline finction that is defined in sys/mutex.h Also compiled into an actual function in kern/mutex.c by including the inlines but removing the word "__inline" The inline version usually knows the constant values of the 'type' argument when expanded and can therefore optimise away all code branches that are not required. Usually this is almost all of the function. It uses the following primatives: _release_lock_quick enable_intr() restore_intr() _exitlock_spin() _exitlock() _exitlock_norecurse() As well as possibly WITNESS_EXIT() if it is defined. mtx_enter_hard() This is a real function, defined in kern/kern_mutex.c. it does all the hard work when a mutex has to stall or otherwise do some hard work. The _getlock (below) primatives call this when things get difficult and slow. calls: mtx_enter() mtx_exit() mtx_assert() _obtain_lock() atomic_set_ptr() atomic_cmpset_ptr() propagate_priority() mi_switch() mtx_exit_hard() This is a real function, defined in kern/kern_mutex.c. it does all the hard work when a mutex has to stall or otherwise do some hard work. The _getlock primatives call this when things get difficult and slow. calls: mtx_enter() mtx_exit() restore_intr() _release_lock_quick() atomic_store_rel_ptr() atomic_clear_ptr() setrunqueue() mi_switch() ================= Basic mutex building blocks ======================== These can have machine dependent versions that can over-ride the machine independent versions. The machine independent versions go on to use more primative operations. (see below) The implement basic parts of locking. _getlock_norecurse() Defined in sys/mutex.h if not defined already. calls _obtain_lock() and mtx_enter_hard() for i386 it has an overriding definition in i386/include/mutex.h (disabled) _getlock_spin_block() Defined in sys/mutex.h if not defined already. Calls save_intr(), disable_intr(), _obtain_lock() and mtx_enter_hard(). Has overriding definitions in alpha/include/mutex.h i386/include/mutex.h (disabled) _getlock_sleep() Defined in sys/mutex.h if not defined already. Calls _obtain_lock(), mtx_enter_hard() and atomic_set_ptr(). For i386 it has an overriding definition in i386/include/mutex.h (disabled) _exitlock_norecurse Defined in sys/mutex.h if not defined already. calls _release_lock() and mtx_exit_hard() for i386 it has an overriding definition in i386/include/mutex.h (disabled) _exitlock Defined in sys/mutex.h if not defined already. calls _release_lock(), atomic_clear_ptr() and mtx_exit_hard() for i386 it has an overriding definition in i386/include/mutex.h (disabled) _exitlock_spin Defined in sys/mutex.h if not defined already. calls _release_lock_quick() and restore_intr() for i386 it has an overriding definition in i386/include/mutex.h (disabled) ============== Macros that implement assembler locking primatives ==== I'm not sure where these are used (I couldn't find any users). Or if they are compatible with the other stuff... are they coming of going? MTX_ENTER() Macro for non recursive spinlocks. (appears unused) alpha/include/mutex.h ia64/include/mutex.h i386/include/mutex.h MTX_ENTER_WITH_RECURSION() macro for recursive locks (appears unused) i386/include/mutex.h MTX_EXIT() Macro for non recursive spinlocks. (appears unused) alpha/include/mutex.h ia64/include/mutex.h i386/include/mutex.h MTX_EXIT_WITH_RECURSION() (appears unused) i386/include/mutex.h ======== Primatives used by MI building blocks. Per processor type ==== disable_intr() | save_intr() | All four are asm inlines defined per_processor restore_intr() | in the following files. enable_intr() | i386/include/cpufunc.h alpha/include/cpufunc.h ia64/include/cpufunc.h ======== Primatives used by MI building blocks. Can be overridden ==== These use the defined "standard MI atomic ops" _obtain_lock() defined in sys/mutex.h but can be over-ridden. calls atomic_cmpset_acq_ptr() _release_lock_quick() defined in sys/mutex.h but can be over-ridden. calls atomic_store_rel_ptr() _release_lock() defined in sys/mutex.h but can be over-ridden. calls atomic_cmpset_rel_ptr() ========= Standard MI atomic ops. Defined per processor.============== atomic stuff defined in {ia64,alpha,i386}/include/atomic.h largely by macros tha produce inline asm functions. only i386 examples detailed here. Note that on the alpha "compare and set" is quite expensive as it takes about 10 instructions. maybe we should use a different primative.. ====================== Examples ====================================== atomic_cmpset_rel_ptr() Defined in i386/include/atomic.h to be the same as: atomic_cmpset_ptr() (below) atomic_cmpset_acq_ptr() Defined in i386/include/atomic.h to be the same as: atomic_cmpset_ptr() (below) atomic_cmpset_ptr() Defined in i386/include/atomic.h using atomic_cmpset_int atomic_load_rel_ptr() Defined in i386/include/atomic.h using atomic_load_acq_int() atomic_store_rel_ptr() Defined in i386/include/atomic.h using atomic_store_rel_int() atomic_clear_ptr() | produced by macros in i386/include/atomic.h atomic_set_ptr() | atomic_cmpset_int() | atomic_store_rel_int | atomic_load_acq_int | ==== EOF===== -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Dec 14 9:59:25 2000 From owner-freebsd-smp@FreeBSD.ORG Thu Dec 14 09:59:23 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 0ECEA37B400 for ; Thu, 14 Dec 2000 09:59:23 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBEHxCE76817; Thu, 14 Dec 2000 09:59:12 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.0) id eBEHwPI39568; Thu, 14 Dec 2000 09:58:25 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3A38E440.B89DA298@elischer.org> Date: Thu, 14 Dec 2000 09:58:20 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Julian Elischer Subject: RE: Mutex roadmap Cc: smp@FreeBSD.ORG Sender: jhb@foo.osd.bsdi.com Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 14-Dec-00 Julian Elischer wrote: > In my attempts to understand locking on behaplf of netgraph, I > ended up writing up this little roadmap of where things are... > > In the hope that SOMEONE finds it useful, I'm posting it here. Some corrections: :) > ============== Macros that implement assembler locking primatives ==== > I'm not sure where these are used (I couldn't find any users). > Or if they are compatible with the other stuff... are they coming of going? MTX_EXIT is used in fork_trampoline() on the x86, and in switch_trampoline() on the alpha and ia64. This specific instance of MTX_EXIT will hopefully be moved out to a MI C function fork_trampoline() that returns to a very short MD stub fork_return in asm. > MTX_ENTER() Macro for non recursive spinlocks. (appears unused) > alpha/include/mutex.h > ia64/include/mutex.h > i386/include/mutex.h Just say 'machine/mutex.h', as it is more concise. :) > ========= Standard MI atomic ops. Defined per processor.============== > atomic stuff defined in {ia64,alpha,i386}/include/atomic.h > largely by macros tha produce inline asm functions. > only i386 examples detailed here. > Note that on the alpha "compare and set" is quite expensive > as it takes about 10 instructions. maybe we should use a different > primative.. On the alpha all of the atomic ops are built from checked loads and conditional stores. It's a RISC chip and doesn't have a 'semaphore' instruction like 'cmpxchg' or 'fetchadd' AFAIK. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Dec 14 11:26:12 2000 From owner-freebsd-smp@FreeBSD.ORG Thu Dec 14 11:26:10 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id AB1C137B400 for ; Thu, 14 Dec 2000 11:26:09 -0800 (PST) Received: from victoria-239.budapest.interware.hu ([195.70.63.239] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 146e11-0000OX-00 for ; Thu, 14 Dec 2000 20:26:08 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A391EA6.AD2C53D4@elischer.org> Date: Thu, 14 Dec 2000 11:25:26 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: smp@freebsd.org Subject: locking and queues etc. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org me again.. I'm lookingat what netgraph should do when it encounters a lock on a node it wants to send data through. The simple answer is to queue the data on the node for processing by whatever presently holds the lock, when they finally finish. I've been looking around however and I haven't noticed any special functions for atomic queue operations. Are these planned? I don;t want to invent my own if others already are working on it. A simple linked list (fifo) is enough for my needs so it should be relatively simple to implement an atomic add/remove. If I've missed it, pointers to the right file would be greatly apreciated.. Julian -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 15 2:57:10 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 15 02:57:09 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 48A9A37B400 for ; Fri, 15 Dec 2000 02:57:08 -0800 (PST) Received: from monrovia-31.budapest.interware.hu ([195.70.53.223] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 146sXy-0001HB-00 for ; Fri, 15 Dec 2000 11:57:06 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A39F8DA.FD4CA0A5@elischer.org> Date: Fri, 15 Dec 2000 02:56:26 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: smp@freebsd.org Subject: atomic increment? Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org CAn we have an atomic increment and decrement primative? presently we get: .L565: movl $1,%eax #APP lock addl %eax,4(%ebx) the movl is totally useless and it would be an absolutly trivial addition.. the question is; is there a religious reason we don't already have it? -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 15 3:31:45 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 15 03:31:42 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from iraun1.ira.uka.de (iraun1.ira.uka.de [129.13.10.90]) by hub.freebsd.org (Postfix) with ESMTP id AB69637B402 for ; Fri, 15 Dec 2000 03:31:41 -0800 (PST) Received: from i30nb2.ira.uka.de by iraun1 (PP) with ESMTP; Fri, 15 Dec 2000 12:31:22 +0100 Received: (from esk@localhost) by i30nb2.ira.uka.de (8.11.0/8.11.1) id eBFBVJA10675; Fri, 15 Dec 2000 12:31:19 +0100 (CET) (envelope-from esk) From: Espen Skoglund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14906.263.346807.179980@i30nb2.ira.uka.de> Date: Fri, 15 Dec 2000 12:31:19 +0100 (CET) To: Julian Elischer Cc: smp@FreeBSD.ORG Subject: Re: atomic increment? In-Reply-To: <3A39F8DA.FD4CA0A5@elischer.org> References: <3A39F8DA.FD4CA0A5@elischer.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Julian Elischer] > CAn we have an atomic increment and decrement primative? > presently we get: > .L565: > movl $1,%eax > #APP > lock > addl %eax,4(%ebx) > the movl is totally useless and it would be an absolutly trivial > addition.. the question is; is there a religious reason we don't > already have it? Couldn't one make use of the __builtin_constant_p() stuff in gcc to optimize this away? (Or maybe that is only applicable to macros -- not to inline functions.) eSk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 15 6: 8:51 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 15 06:08:48 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id F330937B400 for ; Fri, 15 Dec 2000 06:08:47 -0800 (PST) Received: from berserker.bsdi.com (cp@localhost.bsdi.com [127.0.0.1]) by berserker.bsdi.com (8.11.1/8.9.3) with ESMTP id eBFE8PF44272; Fri, 15 Dec 2000 07:08:25 -0700 (MST) (envelope-from cp@berserker.bsdi.com) Message-Id: <200012151408.eBFE8PF44272@berserker.bsdi.com> To: Julian Elischer Cc: smp@FreeBSD.ORG Subject: Re: atomic increment? In-reply-to: Your message of "Fri, 15 Dec 2000 02:56:26 PST." <3A39F8DA.FD4CA0A5@elischer.org> From: Chuck Paterson Date: Fri, 15 Dec 2000 07:08:25 -0700 Sender: cp@berserker.bsdi.com Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian, This is not an argument against, or for, your request. I am sure I am starting to sound like a broken record, but so be it. Please remember that atomic ops are really expensive, at least as expensive as acquiring a mutex. In some cases, of which X86 is not one, they are more expensive than just acquiring the mutex. Typically they are cheaper than acquiring and releasing a mutex, in the case of X86 about half the cost. So, if there are more than two atomic operations and they could have been protected by a single mutex, then the single mutex really is slightly better alternative. At three operations the mutex is a much better alternative. This is not an argument against, or for, your request. Chuck Julian Elischer wrote on: Fri, 15 Dec 2000 02:56:26 PST }CAn we have an atomic increment and decrement primative? } }presently we get: } }.L565: } movl $1,%eax }#APP } lock } addl %eax,4(%ebx) } } }the movl is totally useless and it would be }an absolutly trivial addition.. }the question is; }is there a religious reason we don't already have it? }-- } __--_|\ Julian Elischer } / \ julian@elischer.org } ( OZ ) World tour 2000 }---> X_.---._/ presently in: Budapest } v } } }To Unsubscribe: send mail to majordomo@FreeBSD.org }with "unsubscribe freebsd-smp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 15 8:27:14 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 15 08:27:09 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 2965837B400 for ; Fri, 15 Dec 2000 08:27:08 -0800 (PST) Received: from gaborone-26.budapest.interware.hu ([195.70.52.154] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 146xhI-00066s-00; Fri, 15 Dec 2000 17:27:04 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A3A4630.1905D5D@elischer.org> Date: Fri, 15 Dec 2000 08:26:24 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Chuck Paterson Cc: smp@FreeBSD.ORG Subject: Re: atomic increment? References: <200012151408.eBFE8PF44272@berserker.bsdi.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chuck Paterson wrote: > > Julian, > > This is not an argument against, or for, your request. > > I am sure I am starting to sound like a broken record, > but so be it. Yes you are.. > > Please remember that atomic ops are really expensive, at > least as expensive as acquiring a mutex. That depends on what you wnat to do with them! If I wnat nothing but to write a 1 to a location, and know at teh same time whether the previous contents was a 1 or a 0 then most machines allow that to be done pretty cheaply (2 memory cycles - overlap) A full blown mutex is at least that.. (at a minimum). I'm interested in adding locks to netgraph. If you are trying to bridge two 100Mb ethernets using netgraph, that's up to 300,000 node transitions per second (in each direction if it's full duplex). I DO NOT want to have people complaining that netgraph is too slow because I have to to 600,000 mtx_enters 600,000 mtx_exit's every second. And on top of that if there is a colision, I have to queue the packet on a queue that is guarded in some way, so it's probably closer to 800,000 per second. (don;t mention Gb ethernet) I have the reader/writer locks written and I can use mtx_enter and mtx_exit to make them work, but that's plain disgusting. The reader/writer locks are PEERS of the current mutexes. They should not be clients of them. (see below) > In some cases, of which > X86 is not one, they are more expensive than just acquiring the > mutex. Typically they are cheaper than acquiring and releasing a > mutex, in the case of X86 about half the cost. So why are you against me using atomic ops? I think you just proved my point? But as people have pointed out before, having things like "attommic add N to X" and atomic_cmpxch() is rather foolis because it would be better to implement what people WANT, because what you end up doing is forcing everyone to bang square pegs into round holes everywhere. For example: what I want: and INCREMENT a DECREMENT Why not have them available, optimised for each platform? (many machines have these, and they can be synthesised on most machines that don't, really cheaply) Unfortunatly GCC cannot otimise an __asm add of 1 into an inc, or even an addi (add immediate). I also want a mutex that just stores TRUE or FALSE into something attomically. and returns TRUE (it succeded) or FALSE (it was not free) but I'm forced to use CMPXCG(ptr, MTX_UNOWNED, curproc). This is way overkill for what I want. I don't want the bloody curproc, I want to exclusively lock something and I consider recursion a fatal error. As to what I do think we should do: We should have primatives that are like: struct exclusive_lock *xlock; inline int xlock_get(xlock); inline int xlock_drop(xlock); struct six_lock *sxlock; inline int six_reader(sxlock); (fails of there is a writer running or waiting) inline int six_writer(sxlock); (fails if there are readers or writers) struct recursive_spinlock *rslock; inline int rslock_get(rslock); inline int rslock_grop(rslock); struct sleep_lock *slplock; inline int slplock_get(slplock); inline int slplock_drop(slplock); etc.etc. If you really want to you can implement them using common code, (e.g a wrapper for what we have now) but we wouldn't have the problem we saw a few weeks ago where someone accidentally was sleeping on a lock that others were spinning on. We should also have MI operation macros that do what people want to do rather than implement some virtual machine that other machines may or may-not map to well. I have patches to make SIX (reader/writer) locks as peers of the mtx_xxxx code, and patches that just use them. I would rather use the Peers than the client, but it seems to me that if we are idealogically stuck on this horrible "one huge mutex that does everything" then I need to add my stuff to that, and I would need to get permission from whoever owns that. before I do that. (I.e. add readers and writers counts). It really makes mores sence to me if we had DIFFERENT locks, each specialised for what it does, (maybe with the same debug extensions) and different methods to access them. The if you need to change a lock type, you change it in the containing struct definition and fix all the places that gcc reports to you.. It also alows people to more easily micro optimise the methods. At the moment you need to be confident enough that your optimisation is not going to break some completely different kind of lock. it's all too mixed up.. what happenned to "keep it simple"? Personally I think we should fix this before we get so far into it that it becomes impossible. > > So, if there are more than two atomic operations and they > could have been protected by a single mutex, then the single mutex > really is slightly better alternative. At three operations the > mutex is a much better alternative. > > This is not an argument against, or for, your request. > > Chuck > > Julian Elischer wrote on: Fri, 15 Dec 2000 02:56:26 PST > }CAn we have an atomic increment and decrement primative? > } > }presently we get: > } > }.L565: > } movl $1,%eax > }#APP > } lock > } addl %eax,4(%ebx) > } > } > }the movl is totally useless and it would be > }an absolutly trivial addition.. > }the question is; > }is there a religious reason we don't already have it? > }-- > } __--_|\ Julian Elischer > } / \ julian@elischer.org > } ( OZ ) World tour 2000 > }---> X_.---._/ presently in: Budapest > } v > } > } > }To Unsubscribe: send mail to majordomo@FreeBSD.org > }with "unsubscribe freebsd-smp" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 15 8:29:47 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 15 08:29:45 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 178F837B400 for ; Fri, 15 Dec 2000 08:29:45 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBFGTab14469; Fri, 15 Dec 2000 08:29:36 -0800 (PST) Date: Fri, 15 Dec 2000 08:29:36 -0800 From: Alfred Perlstein To: Chuck Paterson Cc: Julian Elischer , smp@FreeBSD.ORG Subject: Re: atomic increment? Message-ID: <20001215082936.L19572@fw.wintelcom.net> References: <3A39F8DA.FD4CA0A5@elischer.org> <200012151408.eBFE8PF44272@berserker.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012151408.eBFE8PF44272@berserker.bsdi.com>; from cp@bsdi.com on Fri, Dec 15, 2000 at 07:08:25AM -0700 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Julian Elischer wrote on: Fri, 15 Dec 2000 02:56:26 PST > }CAn we have an atomic increment and decrement primative? > } > }presently we get: > } > }.L565: > } movl $1,%eax > }#APP > } lock > } addl %eax,4(%ebx) > } > } > }the movl is totally useless and it would be > }an absolutly trivial addition.. > }the question is; > }is there a religious reason we don't already have it? Check -arch for the flamefest involved, feel free to bring it up with Jason Evans (jasone) if you don't agree. However Chuck Paterson is correct, make sure that if you're going to make a request for them that the thing you are incrementing isn't already under some mutex lock, or should be covered under a mutex lock and all updates done in batch mode. * Chuck Paterson [001215 06:08] wrote: > Julian, > > This is not an argument against, or for, your request. > > I am sure I am starting to sound like a broken record, > but so be it. > > Please remember that atomic ops are really expensive, at > least as expensive as acquiring a mutex. In some cases, of which > X86 is not one, they are more expensive than just acquiring the > mutex. Typically they are cheaper than acquiring and releasing a > mutex, in the case of X86 about half the cost. > > So, if there are more than two atomic operations and they > could have been protected by a single mutex, then the single mutex > really is slightly better alternative. At three operations the > mutex is a much better alternative. > > This is not an argument against, or for, your request. Here's another argument I have for them: On most archs they are both non-blocking and don't disable interrupts. Just another handy feature. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 15 8:38:27 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 15 08:38:25 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 20E1937B400 for ; Fri, 15 Dec 2000 08:38:24 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eBFGc5303027; Fri, 15 Dec 2000 17:38:05 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: Chuck Paterson , Julian Elischer , smp@FreeBSD.ORG Subject: Re: atomic increment? In-Reply-To: Your message of "Fri, 15 Dec 2000 08:29:36 PST." <20001215082936.L19572@fw.wintelcom.net> Date: Fri, 15 Dec 2000 17:38:05 +0100 Message-ID: <3025.976898285@critter> From: Poul-Henning Kamp Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Uhm, I think you guys are talking past each other here. One camp wants code that goes: ... operation (implemented with atom insn) ... The other says, do it this way: ... get_mutex (implemented with atomic insn) operation (normal compiled insn's) release_mutex (implemeted with normal insn) ... It doesn't take a Bruce to see that this is as pointless a dispute as the big vs little endian dispute i Gullivers Travels. But only of course, as long as the operation has no possiblity of blocking, typical examples being "assignment of pointers", arithmetic and so on. My personal take on this is that IFF I i can do it elegantly with simple atomic primitives, I will (see DEVFS), if not I'll use mutexen so that I don't obfuscate the source. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 15 9:47:20 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 15 09:47:18 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 1F40B37B400 for ; Fri, 15 Dec 2000 09:47:17 -0800 (PST) Received: from berserker.bsdi.com (cp@localhost.bsdi.com [127.0.0.1]) by berserker.bsdi.com (8.11.1/8.9.3) with ESMTP id eBFHlAF67343; Fri, 15 Dec 2000 10:47:10 -0700 (MST) (envelope-from cp@berserker.bsdi.com) Message-Id: <200012151747.eBFHlAF67343@berserker.bsdi.com> To: Julian Elischer Cc: smp@FreeBSD.ORG Subject: Re: atomic increment? In-reply-to: Your message of "Fri, 15 Dec 2000 08:26:24 PST." <3A3A4630.1905D5D@elischer.org> From: Chuck Paterson Date: Fri, 15 Dec 2000 10:47:10 -0700 Sender: cp@berserker.bsdi.com Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org } }> }> Please remember that atomic ops are really expensive, at }> least as expensive as acquiring a mutex. } }That depends on what you wnat to do with them! }If I wnat nothing but to write a 1 to a location, and know at teh same }time whether the previous contents was a 1 or a 0 then most machines }allow that to be done pretty cheaply (2 memory cycles - overlap) }A full blown mutex is at least that.. (at a minimum). } 2 locked memory cycles which are a huge number of ordinary instructions. A full blown mutex enter is the same price. }I DO NOT want to have people complaining that netgraph is too slow }because I have to to 600,000 mtx_enters 600,000 mtx_exit's }every second. And on top of that if there is a colision, I have to }queue the packet on a queue that is guarded in some way, so it's probably closer }to }800,000 per second. (don;t mention Gb ethernet) I fully agree. I just don't want people thinking that using atomic operations is a fix for this type of problem. You can't use mutices for each one, and you can't use atomic operations either. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 15 10:50:45 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 15 10:50:42 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id EE91D37B402 for ; Fri, 15 Dec 2000 10:50:41 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBFInuE23369; Fri, 15 Dec 2000 10:49:56 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3A3A4630.1905D5D@elischer.org> Date: Fri, 15 Dec 2000 10:50:12 -0800 (PST) From: John Baldwin To: Julian Elischer Subject: Re: atomic increment? Cc: smp@FreeBSD.org, Chuck Paterson Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > If you really want to you can implement them using common code, > (e.g a wrapper for what we have now) > but we wouldn't have the problem we saw a few weeks ago where > someone accidentally was sleeping on a lock that others were > spinning on. Umm, we had that problem? Really? I must've missed that.... As for having reader/writer lock implementation that doesn't depend on mutexes, that is fine with me. But for now just whip up one that _works_ and make your API general enough. Then you can optimize it later. However, if we are adding reader/writer locks to the code, we want to not have to debug the locks and the code at the same time. Using an API means we can always optimize these later. If we don't actually work on getting locks into the kernel then it doesn't matter if we have the world's fastest reader/writer locks. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 15 10:50:45 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 15 10:50:42 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id EDE7737B400 for ; Fri, 15 Dec 2000 10:50:41 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBFIntE23365; Fri, 15 Dec 2000 10:49:55 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3A39F8DA.FD4CA0A5@elischer.org> Date: Fri, 15 Dec 2000 10:50:12 -0800 (PST) From: John Baldwin To: Julian Elischer Subject: RE: atomic increment? Cc: smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 15-Dec-00 Julian Elischer wrote: > CAn we have an atomic increment and decrement primative? > > presently we get: > > .L565: > movl $1,%eax >#APP > lock > addl %eax,4(%ebx) > > > the movl is totally useless and it would be > an absolutly trivial addition.. > the question is; > is there a religious reason we don't already have it? man atomic -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 15 10:56:12 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 15 10:56:10 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3FAA437B400; Fri, 15 Dec 2000 10:56:06 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBFIu6f19245; Fri, 15 Dec 2000 10:56:06 -0800 (PST) Date: Fri, 15 Dec 2000 10:56:06 -0800 From: Alfred Perlstein To: John Baldwin Cc: Julian Elischer , smp@FreeBSD.ORG Subject: Re: atomic increment? Message-ID: <20001215105605.S19572@fw.wintelcom.net> References: <3A39F8DA.FD4CA0A5@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Fri, Dec 15, 2000 at 10:50:12AM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * John Baldwin [001215 10:51] wrote: > > On 15-Dec-00 Julian Elischer wrote: > > CAn we have an atomic increment and decrement primative? > > > > presently we get: > > > > .L565: > > movl $1,%eax > >#APP > > lock > > addl %eax,4(%ebx) > > > > > > the movl is totally useless and it would be > > an absolutly trivial addition.. > > the question is; > > is there a religious reason we don't already have it? > > man atomic I think he's looking for a useable and intuative interface. no offence I hope. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 15 11: 2:10 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 15 11:02:08 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id F0C5E37B400 for ; Fri, 15 Dec 2000 11:02:07 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBFJ1nE23658; Fri, 15 Dec 2000 11:01:49 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001215105605.S19572@fw.wintelcom.net> Date: Fri, 15 Dec 2000 11:02:05 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: atomic increment? Cc: smp@FreeBSD.org, Julian Elischer Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 15-Dec-00 Alfred Perlstein wrote: > * John Baldwin [001215 10:51] wrote: >> >> On 15-Dec-00 Julian Elischer wrote: >> > CAn we have an atomic increment and decrement primative? >> > >> > presently we get: >> > >> > .L565: >> > movl $1,%eax >> >#APP >> > lock >> > addl %eax,4(%ebx) >> > >> > >> > the movl is totally useless and it would be >> > an absolutly trivial addition.. >> > the question is; >> > is there a religious reason we don't already have it? >> >> man atomic > > I think he's looking for a useable and intuative interface. > > no offence I hope. :) I didn't come up with it. :) atomic_add_int(&my_int_var, 1) doesn't appear too weird to me. Of course, the movl being complained about is actually rather rediculous. It's in the instruction cache, so the '1' is a cache hit, and this instruction is probably all of 1 clock. Compared to the overhead of the bus lock, that is completely lost in the noise. Also, staring at the microcosm of the asm on one machine is not necessarily going to apply to other machines at all. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 15 14:45:35 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 15 14:45:33 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 4544437B400; Fri, 15 Dec 2000 14:45:32 -0800 (PST) Received: from luanda-49.budapest.interware.hu ([195.70.51.49] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 1473bP-0005de-00; Fri, 15 Dec 2000 23:45:24 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A3A9EDB.C8229E40@elischer.org> Date: Fri, 15 Dec 2000 14:44:43 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin Cc: smp@FreeBSD.org Subject: Re: atomic increment? References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Baldwin wrote: > > On 15-Dec-00 Julian Elischer wrote: > > CAn we have an atomic increment and decrement primative? > > > > presently we get: > > > > .L565: > > movl $1,%eax > >#APP > > lock > > addl %eax,4(%ebx) > > > > > > the movl is totally useless and it would be > > an absolutly trivial addition.. > > the question is; > > is there a religious reason we don't already have it? > > man atomic man atomic doesn't mention increment, just addition, which is what I used to get the (annoying) code above. Gcc has to supply the '1' as astandard argument and can not optimise it. It we had a 'standard op of 'inc' then the argument is un-needed which frees up a register which may make other code more efficient, and it reduces the instruction stream chunk used by the code leaving more of the readahead for useful information. it's not a major thing but since increment and decrement by a set amount is very common (all the lock examples you find use them) it seems a logical thing to actually define in an efficient manner. > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 15 14:46:56 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 15 14:46:53 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 7DF2637B400; Fri, 15 Dec 2000 14:46:52 -0800 (PST) Received: from luanda-49.budapest.interware.hu ([195.70.51.49] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 1473co-0005jn-00; Fri, 15 Dec 2000 23:46:50 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A3A9F32.3C6E1B0E@elischer.org> Date: Fri, 15 Dec 2000 14:46:10 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Alfred Perlstein Cc: John Baldwin , smp@FreeBSD.ORG Subject: Re: atomic increment? References: <3A39F8DA.FD4CA0A5@elischer.org> <20001215105605.S19572@fw.wintelcom.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred Perlstein wrote: > > * John Baldwin [001215 10:51] wrote: > > > > On 15-Dec-00 Julian Elischer wrote: > > > CAn we have an atomic increment and decrement primative? > > > > > > presently we get: > > > > > > .L565: > > > movl $1,%eax > > >#APP > > > lock > > > addl %eax,4(%ebx) > > > > > > > > > the movl is totally useless and it would be > > > an absolutly trivial addition.. > > > the question is; > > > is there a religious reason we don't already have it? > > > > man atomic > > I think he's looking for a useable and intuative interface. that would be the one.. :-) . > > no offence I hope. :) > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 15 14:51:38 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 15 14:51:34 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 9577237B699; Fri, 15 Dec 2000 14:51:33 -0800 (PST) Received: from luanda-49.budapest.interware.hu ([195.70.51.49] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 1473hL-00064E-00; Fri, 15 Dec 2000 23:51:32 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A3AA04B.68EEB813@elischer.org> Date: Fri, 15 Dec 2000 14:50:51 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin Cc: Alfred Perlstein , smp@FreeBSD.org Subject: Re: atomic increment? References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Baldwin wrote: > > On 15-Dec-00 Alfred Perlstein wrote: > > * John Baldwin [001215 10:51] wrote: > >> > >> On 15-Dec-00 Julian Elischer wrote: > >> > CAn we have an atomic increment and decrement primative? > >> > > >> > presently we get: > >> > > >> > .L565: > >> > movl $1,%eax > >> >#APP > >> > lock > >> > addl %eax,4(%ebx) > >> > > >> > > >> > the movl is totally useless and it would be > >> > an absolutly trivial addition.. > >> > the question is; > >> > is there a religious reason we don't already have it? > >> > >> man atomic > > > > I think he's looking for a useable and intuative interface. > > > > no offence I hope. :) > > I didn't come up with it. :) atomic_add_int(&my_int_var, 1) doesn't appear too > weird to me. Of course, the movl being complained about is actually rather > rediculous. It's in the instruction cache, so the '1' is a cache hit, and this > instruction is probably all of 1 clock. Compared to the overhead of the bus > lock, that is completely lost in the noise. Also, staring at the microcosm of > the asm on one machine is not necessarily going to apply to other machines at > all. the mov uses up a register which in one example I was using here, forced a much needed number to be written to memory and later restored. That caused 1/ Extra delay as some percentage of the read-ahead cache was used by the move. I'm sure it was not a lot but it probably pused something else back a bit maing it slightly less likely to be in by the time it was needed. 2/ Cluttering of the registers.. which forced: 3/ extra bus cycles as the processor wrote values to memory (for no real reason) > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Dec 16 4:59:45 2000 From owner-freebsd-smp@FreeBSD.ORG Sat Dec 16 04:59:43 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id CFEFC37B400; Sat, 16 Dec 2000 04:59:40 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA19742; Sat, 16 Dec 2000 23:59:29 +1100 Date: Sat, 16 Dec 2000 23:59:28 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Julian Elischer Cc: John Baldwin , Alfred Perlstein , smp@FreeBSD.ORG Subject: Re: atomic increment? In-Reply-To: <3A3AA04B.68EEB813@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 15 Dec 2000, Julian Elischer wrote: > John Baldwin wrote: > > > > On 15-Dec-00 Alfred Perlstein wrote: > > > * John Baldwin [001215 10:51] wrote: > > >> > > >> On 15-Dec-00 Julian Elischer wrote: > > >> > CAn we have an atomic increment and decrement primative? No. They are just syntactic sugar for adding and subtracting 1. > > >> > presently we get: > > >> > > > >> > .L565: > > >> > movl $1,%eax > > >> >#APP > > >> > lock > > >> > addl %eax,4(%ebx) > > >> > > > >> > > > >> > the movl is totally useless and it would be > > >> > an absolutly trivial addition.. The movl is a gcc pessimization. gcc should generate: lock addl $1,4(%ebx) gcc did generate this for old versions of the atomic functions (it only started pessimizing this when we added some `volatile' qualifiers). The above (addl $1...) has exactly the same overheads as: lock incl 4(%ebx) except it is 1 byte longer so it may take longer to fetch (but instruction fetching hasn't been a significant bottleneck since the original 386, and I think the instruction fetcher will have even more time to keep up than usual because the lock instruction slows things down). > > I didn't come up with it. :) atomic_add_int(&my_int_var, 1) doesn't appear too > > weird to me. Of course, the movl being complained about is actually rather > > rediculous. It's in the instruction cache, so the '1' is a cache hit, and this > > instruction is probably all of 1 clock. Compared to the overhead of the bus Or 0 clocks, if it is done in parallel with the previous instruction. > the mov uses up a register which in one example I was using here, forced > a much needed number to be written to memory and later restored. True, but this is gcc's fault. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Dec 16 8:30:20 2000 From owner-freebsd-smp@FreeBSD.ORG Sat Dec 16 08:30:17 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id BF47E37B400; Sat, 16 Dec 2000 08:30:16 -0800 (PST) Received: from berserker.bsdi.com (cp@localhost.bsdi.com [127.0.0.1]) by berserker.bsdi.com (8.11.1/8.9.3) with ESMTP id eBGGTsP05883; Sat, 16 Dec 2000 09:29:54 -0700 (MST) (envelope-from cp@berserker.bsdi.com) Message-Id: <200012161629.eBGGTsP05883@berserker.bsdi.com> To: Bruce Evans Cc: Julian Elischer , John Baldwin , Alfred Perlstein , smp@FreeBSD.ORG Subject: Re: atomic increment? In-reply-to: Your message of "Sat, 16 Dec 2000 23:59:28 +1100." From: Chuck Paterson Date: Sat, 16 Dec 2000 09:29:54 -0700 Sender: cp@berserker.bsdi.com Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Actually performaning the volatile function ->>may<<- have reduced register pressure resulting in gcc using the load eax. There sure isn't much which gcc is going to believe is save to leave in a register across this instruction sequence once it is tagged as volatile. This does bring up the point that not all use of atomic ops are equal. There are those which must not only have the locked prefix to make the operation work but must be executed in the correct place in the instruction stream to get correct overall semantics. On the other hand there are those, such a stat counters, which only need the lock prefix. These uses really shouldn't require being tagged as volatile. Chuck Bruce Evans wrote on: Sat, 16 Dec 2000 23:59:28 +1100 }The movl is a gcc pessimization. gcc should generate: } } lock } addl $1,4(%ebx) } }gcc did generate this for old versions of the atomic functions (it }only started pessimizing this when we added some `volatile' qualifiers). } }The above (addl $1...) has exactly the same overheads as: } } lock } incl 4(%ebx) } }except it is 1 byte longer so it may take longer to fetch (but }instruction fetching hasn't been a significant bottleneck since the }original 386, and I think the instruction fetcher will have even more }time to keep up than usual because the lock instruction slows things }down). } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Dec 16 9:41:55 2000 From owner-freebsd-smp@FreeBSD.ORG Sat Dec 16 09:41:53 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id E546337B400; Sat, 16 Dec 2000 09:41:52 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id eBGHfke31398; Sat, 16 Dec 2000 12:41:47 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 16 Dec 2000 12:41:46 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Baldwin Cc: smp@FreeBSD.org Subject: Re: cvs commit: src/sys/sys proc.h In-Reply-To: <200012150010.eBF0AX468476@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: robert@fledge.watson.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org BTW, I don't know if you've had a chance to look at individual process locking in kern_proc.c yet, but if so then the sysctl code to retrieve process info will need some of the same work during kproc_info extraction (protecting pcred, etc). Also, p_can* will have to assume that the process mutexes for p1 and p2 are both already held (so as to avoid recursion issues), so callers of p_can (especially in procfs and signalling code) will need to reflect that assumption. We should grep through for any direct references to p_cred throughout the tree, and where possible eliminate them by improving authorization abstractions (if I missed any inter-process calls), and where not, make sure they're properly protected and documented (get/set-uid calls, sysctl, etc). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Dec 16 10:47: 7 2000 From owner-freebsd-smp@FreeBSD.ORG Sat Dec 16 10:47:05 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 4A3B337B402; Sat, 16 Dec 2000 10:47:05 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBGIknE60182; Sat, 16 Dec 2000 10:46:49 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.0) id eBGIjxi62529; Sat, 16 Dec 2000 10:45:59 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 16 Dec 2000 10:45:59 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Robert Watson Subject: Re: cvs commit: src/sys/sys proc.h Cc: smp@FreeBSD.ORG Sender: jhb@foo.osd.bsdi.com Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 16-Dec-00 Robert Watson wrote: > > BTW, I don't know if you've had a chance to look at individual process > locking in kern_proc.c yet, but if so then the sysctl code to retrieve > process info will need some of the same work during kproc_info extraction > (protecting pcred, etc). Also, p_can* will have to assume that the > process mutexes for p1 and p2 are both already held (so as to avoid > recursion issues), so callers of p_can (especially in procfs and > signalling code) will need to reflect that assumption. We should grep > through for any direct references to p_cred throughout the tree, and where > possible eliminate them by improving authorization abstractions (if I > missed any inter-process calls), and where not, make sure they're properly > protected and documented (get/set-uid calls, sysctl, etc). Hmm, ok. I think I've seen one direct p_cred reference that wasn't to pc_ucred so far in sys/compat/svr4. I'll have to look at p_can* in a little more detail. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message