From owner-freebsd-smp@FreeBSD.ORG Sun Jun 13 00:13:29 2004 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37AFC16A4CE for ; Sun, 13 Jun 2004 00:13:29 +0000 (GMT) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3D9443D1F for ; Sun, 13 Jun 2004 00:13:28 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.11/8.12.11) with ESMTP id i5D0CdNd014491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 12 Jun 2004 17:12:40 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.11/8.12.11/Submit) id i5D0CdWJ045741 for freebsd-smp@freebsd.org; Sat, 12 Jun 2004 17:12:39 -0700 (PDT) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 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, 12 Jun 2004 17:12:39 -0700 (PDT) From: John Polstra To: freebsd-smp@freebsd.org X-Bogosity: No, tests=bogofilter, spamicity=0.352351, version=0.14.5 Subject: RE: Question about cv_signal(9) (never mind) X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2004 00:13:29 -0000 On 12-Jun-2004 John Polstra wrote: > [Why does a caller to cv_signal(9) have to hold the associated mutex?] Never mind. I understand now. It allows the implementation to avoid doing any locking internally. That seems perfectly reasonable, and I withdraw my question. John From owner-freebsd-smp@FreeBSD.ORG Mon Jun 14 11:36:16 2004 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C532516A4CE for ; Mon, 14 Jun 2004 11:36:16 +0000 (GMT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id E993343D58 for ; Mon, 14 Jun 2004 11:36:15 +0000 (GMT) (envelope-from free.bsd@gmx.net) Received: (qmail 26116 invoked by uid 0); 14 Jun 2004 11:35:58 -0000 Received: from 141.20.195.229 by www67.gmx.net with HTTP; Mon, 14 Jun 2004 13:35:58 +0200 (MEST) Date: Mon, 14 Jun 2004 13:35:58 +0200 (MEST) From: "freebsd_daemon" To: freebsd-smp@freebsd.org MIME-Version: 1.0 X-Priority: 3 (Normal) X-Authenticated: #20105305 Message-ID: <20281.1087212958@www67.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Single Xeon X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 11:36:16 -0000 Dear list; will all Xeons also run if no second CPU (Xeon) is available? I need to know as i am building a system to be used by a small number of people, but don't know how many it eventually will become. I therefore would like to keep the system as scaleable as possible and would like to use a dual board but start with only one CPU. TIA Zheyu -- +++ Jetzt WLAN-Router fЭr alle DSL-Einsteiger und Wechsler +++ GMX DSL-Powertarife zudem 3 Monate gratis* http://www.gmx.net/dsl From owner-freebsd-smp@FreeBSD.ORG Mon Jun 14 12:22:44 2004 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C560E16A4CE for ; Mon, 14 Jun 2004 12:22:44 +0000 (GMT) Received: from santiago.pacific.net.sg (santiago.pacific.net.sg [203.120.90.135]) by mx1.FreeBSD.org (Postfix) with SMTP id 9AE2F43D41 for ; Mon, 14 Jun 2004 12:22:43 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: (qmail 5311 invoked from network); 14 Jun 2004 12:22:42 -0000 Received: from unknown (HELO maxwell6.pacific.net.sg) (203.120.90.212) by santiago with SMTP; 14 Jun 2004 12:22:41 -0000 Received: from pacific.net.sg ([210.24.202.26]) by maxwell6.pacific.net.sg with ESMTP id <20040614122241.WMQT8220.maxwell6.pacific.net.sg@pacific.net.sg>; Mon, 14 Jun 2004 20:22:41 +0800 Message-ID: <40CD988B.5010107@pacific.net.sg> Date: Mon, 14 Jun 2004 20:22:35 +0800 From: Erich Dollansky Organization: oceanare pte ltd User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7b) Gecko/20040409 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd_daemon References: <20281.1087212958@www67.gmx.net> In-Reply-To: <20281.1087212958@www67.gmx.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-smp@freebsd.org Subject: Re: Single Xeon X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 12:22:44 -0000 Hi, freebsd_daemon wrote: > Dear list; > > will all Xeons also run if no second CPU (Xeon) is available? > I think so. > I need to know as i am building a system to be used by a small number of > people, but don't know how many it eventually will become. I therefore would > like to keep the system as scaleable as possible and would like to use a > dual board but start with only one CPU. > Your problem will be that you will not get the second CPU when you actually will need it or you will end up paying a very high price for it. You might start with two CPUs but with a cheaper or even with the cheapest version. Erich From owner-freebsd-smp@FreeBSD.ORG Mon Jun 14 13:02:33 2004 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1316C16A4D4 for ; Mon, 14 Jun 2004 13:02:33 +0000 (GMT) Received: from master.plesk.ru (nsk-gw.sw-soft.com [80.89.140.126]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8332443D54 for ; Mon, 14 Jun 2004 13:02:31 +0000 (GMT) (envelope-from kpisman@sw-soft.com) Received: from [192.168.42.23] (Pisman.plesk.ru [192.168.42.23]) by master.plesk.ru (8.12.10/8.12.8) with ESMTP id i5ED2KaB080072 for ; Mon, 14 Jun 2004 20:02:21 +0700 (NOVST) (envelope-from kpisman@sw-soft.com) From: Kirill Pisman To: freebsd-smp@freebsd.org In-Reply-To: <20281.1087212958@www67.gmx.net> References: <20281.1087212958@www67.gmx.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-nmuRjaaDCnRzx4ynK5ZA" Organization: SW Soft Message-Id: <1087218149.12067.7.camel@nothing.plesk.ru> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 14 Jun 2004 20:02:31 +0700 Subject: Re: Single Xeon X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kpisman@sw-soft.com List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 13:02:33 -0000 --=-nmuRjaaDCnRzx4ynK5ZA Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable =F7 =D0=CE, 14.06.2004, =D7 18:35, freebsd_daemon =D0=C9=DB=C5=D4: > Dear list; >=20 > will all Xeons also run if no second CPU (Xeon) is available? Some time ago there was troubles with usage of two CPU's from different series together, so possible you will have to bye 3 CPU's finally, because first one will not work with next. It was so on P-3 Coppermine , and tualatin, and i don't think that something is changed. So maybe it will be better to bye 2 CPU's one time? As i know any intel CPU will work in single mode.And again last tests - is p-3 age. But not any motherboard will work with one CPU, as i know. PS maybe google will give you the better results, or just someone else. --=20 Kirill Pisman kirill@pisman.info http://pisman.info Penguins can't fly. --=-nmuRjaaDCnRzx4ynK5ZA Content-Type: application/pgp-signature; name=signature.asc Content-Description: =?koi8-r?Q?=FC=D4=C1?= =?koi8-r?Q?_=DE=C1=D3=D4=D8?= =?koi8-r?Q?_=D3=CF=CF=C2=DD=C5=CE=C9=D1?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=C1=CE=C1?= =?koi8-r?Q?_=C3=C9=C6=D2=CF=D7=CF=CA?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=D8=C0?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQBAzaHlrHLg7wjBnDsRAnIFAJ0eVxZVwci+x/lLi7XHBF0ofF9o+QCdEUnY uFHVJZHCyEX6fRt20f5PzjQ= =O+cN -----END PGP SIGNATURE----- --=-nmuRjaaDCnRzx4ynK5ZA-- From owner-freebsd-smp@FreeBSD.ORG Mon Jun 14 13:43:34 2004 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D67EA16A4CE for ; Mon, 14 Jun 2004 13:43:34 +0000 (GMT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ECE443D2D for ; Mon, 14 Jun 2004 13:43:34 +0000 (GMT) (envelope-from john.cagle@hp.com) Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.81.1.35]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id B1FC43B9; Mon, 14 Jun 2004 08:43:14 -0500 (CDT) Received: from cceexc19.americas.cpqcorp.net ([16.81.1.19]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 14 Jun 2004 08:42:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Jun 2004 08:42:52 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Single Xeon Thread-Index: AcRSBoVDc2O3ALBnSSeZelu6y4YOZAADnV+w From: "Cagle, John (ISS-Houston)" To: "freebsd_daemon" X-OriginalArrivalTime: 14 Jun 2004 13:42:54.0480 (UTC) FILETIME=[7E968100:01C45215] cc: freebsd-smp@freebsd.org Subject: RE: Single Xeon X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 13:43:34 -0000 Zheyu wrote: > -----Original Message----- > Dear list; >=20 > will all Xeons also run if no second CPU (Xeon) is available? >=20 > I need to know as i am building a system to be used by a=20 > small number of > people, but don't know how many it eventually will become. I=20 > therefore would > like to keep the system as scaleable as possible and would=20 > like to use a > dual board but start with only one CPU. Yes, certainly a single Xeon will work by itself, even the MP version (which is for use in 4-way systems). Regards, John ----------------------------- John Cagle john.cagle@hp.com HP Distinguished Technologist ProLiant Software Development Hewlett-Packard Company From owner-freebsd-smp@FreeBSD.ORG Mon Jun 14 18:44:25 2004 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DB3F16A4CF for ; Mon, 14 Jun 2004 18:44:25 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41C5D43D1D for ; Mon, 14 Jun 2004 18:44:25 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4482 invoked from network); 14 Jun 2004 18:43:46 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 14 Jun 2004 18:43:46 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i5EIhh3d058089; Mon, 14 Jun 2004 14:43:43 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-smp@FreeBSD.org Date: Mon, 14 Jun 2004 14:44:38 -0400 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406141444.38269.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: John Polstra Subject: Re: Question about cv_signal(9) (never mind) X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 18:44:25 -0000 On Saturday 12 June 2004 08:12 pm, John Polstra wrote: > On 12-Jun-2004 John Polstra wrote: > > [Why does a caller to cv_signal(9) have to hold the associated mutex?] > > Never mind. I understand now. It allows the implementation to > avoid doing any locking internally. That seems perfectly > reasonable, and I withdraw my question. To be honest, it's also largely there to try to keep people from writing code that can lose wakeups. The count optimization came later. If the optimization of dropping the lock is more important and we think that people really won't make the mistake of not using locks when they should to avoid the lost wakeups then we could drop the count optimization and allow cv_signal() to not require the lock perhaps. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-smp@FreeBSD.ORG Mon Jun 14 18:53:28 2004 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB7B516A4CE; Mon, 14 Jun 2004 18:53:28 +0000 (GMT) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4251543D1D; Mon, 14 Jun 2004 18:53:28 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.11/8.12.11) with ESMTP id i5EIrDsk035184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jun 2004 11:53:13 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.11/8.12.11/Submit) id i5EIrDJv048680; Mon, 14 Jun 2004 11:53:13 -0700 (PDT) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200406141444.38269.jhb@FreeBSD.org> Date: Mon, 14 Jun 2004 11:53:13 -0700 (PDT) From: John Polstra To: John Baldwin X-Bogosity: No, tests=bogofilter, spamicity=0.334851, version=0.14.5 cc: freebsd-smp@FreeBSD.org Subject: Re: Question about cv_signal(9) (never mind) X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 18:53:29 -0000 On 14-Jun-2004 John Baldwin wrote: > On Saturday 12 June 2004 08:12 pm, John Polstra wrote: >> On 12-Jun-2004 John Polstra wrote: >> > [Why does a caller to cv_signal(9) have to hold the associated mutex?] >> >> Never mind. I understand now. It allows the implementation to >> avoid doing any locking internally. That seems perfectly >> reasonable, and I withdraw my question. > > To be honest, it's also largely there to try to keep people from writing code > that can lose wakeups. The count optimization came later. If the > optimization of dropping the lock is more important and we think that people > really won't make the mistake of not using locks when they should to avoid > the lost wakeups then we could drop the count optimization and allow > cv_signal() to not require the lock perhaps. It seems to me that some sort of mutual exclusion is needed when manipulating the cv structure and the associated sleep queue. If the user doesn't provide it then the implementation will have to provide it internally. So unless there is a cheaper kind of mutual exclusion that can be used inside the implementation, your current solution seems the best to me. I had never thought through the need for some kind of mutual exclusion, and the papers that describe the optimization I mentioned simply ignore it and its performance implications. John From owner-freebsd-smp@FreeBSD.ORG Mon Jun 14 19:02:48 2004 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9D3616A4CE for ; Mon, 14 Jun 2004 19:02:48 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83D3643D54 for ; Mon, 14 Jun 2004 19:02:48 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 25010 invoked from network); 14 Jun 2004 19:02:39 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 14 Jun 2004 19:02:39 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i5EJ2Z0H058301; Mon, 14 Jun 2004 15:02:36 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: John Polstra Date: Mon, 14 Jun 2004 15:03:30 -0400 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406141503.30426.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-smp@FreeBSD.org Subject: Re: Question about cv_signal(9) (never mind) X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 19:02:48 -0000 On Monday 14 June 2004 02:53 pm, John Polstra wrote: > On 14-Jun-2004 John Baldwin wrote: > > On Saturday 12 June 2004 08:12 pm, John Polstra wrote: > >> On 12-Jun-2004 John Polstra wrote: > >> > [Why does a caller to cv_signal(9) have to hold the associated mutex?] > >> > >> Never mind. I understand now. It allows the implementation to > >> avoid doing any locking internally. That seems perfectly > >> reasonable, and I withdraw my question. > > > > To be honest, it's also largely there to try to keep people from writing > > code that can lose wakeups. The count optimization came later. If the > > optimization of dropping the lock is more important and we think that > > people really won't make the mistake of not using locks when they should > > to avoid the lost wakeups then we could drop the count optimization and > > allow cv_signal() to not require the lock perhaps. > > It seems to me that some sort of mutual exclusion is needed when > manipulating the cv structure and the associated sleep queue. If > the user doesn't provide it then the implementation will have to > provide it internally. So unless there is a cheaper kind of mutual > exclusion that can be used inside the implementation, your current > solution seems the best to me. > > I had never thought through the need for some kind of mutual > exclusion, and the papers that describe the optimization I mentioned > simply ignore it and its performance implications. Well, the sleep queue is not protected by the data lock, it is protected by a spin lock associated with the hash table bucket that the condition variable's address hashes to. Specifically, note that sleepq_lookup() locks the associated spin lock and returns with it locked where as sleepq_release(), etc. unlocks the spin lock. The sleepq is locked inside sleepq_signal() and sleepq_wakeup(). If you don't implement the count optimization, then cv_signal() just calls sleepq_signal() and cv_wakeup() just calls sleepq_wakeup() with no need for any locking of the cv structure itself. See rev 1.47 of kern_condvar.c and the current implementations of wakeup() and wakeup_one() for example. The other member of struct condvar is static in that it is only set during initialization and doesn't need any locking. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-smp@FreeBSD.ORG Mon Jun 14 19:15:58 2004 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6613616A4CE; Mon, 14 Jun 2004 19:15:58 +0000 (GMT) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3BD243D5F; Mon, 14 Jun 2004 19:15:57 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.11/8.12.11) with ESMTP id i5EJFveg035471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jun 2004 12:15:57 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.11/8.12.11/Submit) id i5EJFvf4048728; Mon, 14 Jun 2004 12:15:57 -0700 (PDT) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200406141503.30426.jhb@FreeBSD.org> Date: Mon, 14 Jun 2004 12:15:57 -0700 (PDT) From: John Polstra To: John Baldwin X-Bogosity: No, tests=bogofilter, spamicity=0.481204, version=0.14.5 cc: freebsd-smp@FreeBSD.org Subject: Re: Question about cv_signal(9) (never mind) X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 19:15:58 -0000 On 14-Jun-2004 John Baldwin wrote: > On Monday 14 June 2004 02:53 pm, John Polstra wrote: >> On 14-Jun-2004 John Baldwin wrote: >> > On Saturday 12 June 2004 08:12 pm, John Polstra wrote: >> >> On 12-Jun-2004 John Polstra wrote: >> >> > [Why does a caller to cv_signal(9) have to hold the associated mutex?] >> >> >> >> Never mind. I understand now. It allows the implementation to >> >> avoid doing any locking internally. That seems perfectly >> >> reasonable, and I withdraw my question. >> > >> > To be honest, it's also largely there to try to keep people from writing >> > code that can lose wakeups. The count optimization came later. If the >> > optimization of dropping the lock is more important and we think that >> > people really won't make the mistake of not using locks when they should >> > to avoid the lost wakeups then we could drop the count optimization and >> > allow cv_signal() to not require the lock perhaps. >> >> It seems to me that some sort of mutual exclusion is needed when >> manipulating the cv structure and the associated sleep queue. If >> the user doesn't provide it then the implementation will have to >> provide it internally. So unless there is a cheaper kind of mutual >> exclusion that can be used inside the implementation, your current >> solution seems the best to me. >> >> I had never thought through the need for some kind of mutual >> exclusion, and the papers that describe the optimization I mentioned >> simply ignore it and its performance implications. > > Well, the sleep queue is not protected by the data lock, it is protected by a > spin lock associated with the hash table bucket that the condition variable's > address hashes to. Specifically, note that sleepq_lookup() locks the > associated spin lock and returns with it locked where as sleepq_release(), > etc. unlocks the spin lock. The sleepq is locked inside sleepq_signal() and > sleepq_wakeup(). If you don't implement the count optimization, then > cv_signal() just calls sleepq_signal() and cv_wakeup() just calls > sleepq_wakeup() with no need for any locking of the cv structure itself. See > rev 1.47 of kern_condvar.c and the current implementations of wakeup() and > wakeup_one() for example. The other member of struct condvar is static in > that it is only set during initialization and doesn't need any locking. Thanks for clarifying that. In that case, I think it's definitely worthwhile to remove the requirement that the caller hold the mutex when calling cv_signal. I remember reading about some benchmark results once (using userland POSIX threads) in which applying the simple wakeup optimization made a very significant improvement. Sorry for the lack of specifics here. It was a long time ago. Measurements aside, it's clear that the current restriction practically guarantees two context switches for every condvar wakeup. Reducing that to one context switch would surely be worthwhile. I think the kinds of bugs that cause programmers to lose wakeups usually occur in the code that's waiting rather than in the code that's signaling. So lifting the restriction probably wouldn't result in folks making any mistakes that they wouldn't have made regardless. Also, anybody who's had experience using POSIX threads is already used to the idea of not having to hold the mutex when signaling the condition variable. John From owner-freebsd-smp@FreeBSD.ORG Tue Jun 15 18:50:45 2004 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73ED816A507; Tue, 15 Jun 2004 18:50:44 +0000 (GMT) Received: from mail.ngdc.net (mail.ngdc.net [195.190.153.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2A9743D4C; Tue, 15 Jun 2004 18:50:43 +0000 (GMT) (envelope-from laursen@netgroup.dk) Received: from animal (port390.ds1-noe.adsl.cybercity.dk [217.157.177.19]) (AUTH: LOGIN laursen@solidcore.dk) by bunsen.solidcore.dk with esmtp; Tue, 15 Jun 2004 20:50:02 +0200 Message-ID: <08d001c45309$8ac93630$ce01000a@animal> From: "Lasse Laursen" To: "Daniel Eischen" , freebsd-smp@freebsd.org References: Date: Tue, 15 Jun 2004 20:49:20 +0200 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 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 cc: freebsd-threads@freebsd.org Subject: Re: Possible Threading problem with -CURRENT / MySQL? X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2004 18:50:46 -0000 Hi again, The system still "locks up" on some queries after HTT has been disabled and all memory options removed from the kernel. I have posted this on the freebsd-smp@freebsd.org as well since it's probably a more suitable place for this bug/problem. Thank you all for your suggestions so far :) Regards -- Lasse Laursen ╥ VP, Hosting Technology ╥ NetGroup Processing Aps St. Kongensgade 40H ╥ DK-1264 Copenhagen K, Denmark Phone: +45 3370 1526 ╥ Fax: +45 3313 0066 - Don't be fooled by cheap finnish imitations - BSD is the One True Code ----- Original Message ----- From: "Daniel Eischen" To: "JG" Cc: Sent: Tuesday, June 15, 2004 6:51 PM Subject: Re: Possible Threading problem with -CURRENT / MySQL? > On Tue, 15 Jun 2004, JG wrote: > His lockups are complete; yours are not. Also, others have mentioned > that HTT causes problems. Please let him try various things instead > of discouraging him. Any information he can give us is helpful. > > > Robert Watson said he was going to try to look into this problem within the > > next few days. From owner-freebsd-smp@FreeBSD.ORG Thu Jun 17 08:42:02 2004 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D39816A4CE for ; Thu, 17 Jun 2004 08:42:02 +0000 (GMT) Received: from may.priocom.com (may.priocom.com [213.156.65.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADAA443D66 for ; Thu, 17 Jun 2004 08:42:01 +0000 (GMT) (envelope-from osspam@ukrpost.net) Received: from [82.207.30.217] (helo=win2k) by may.priocom.com with asmtp (Exim 4.24) id 1BasPc-00014A-Vw for freebsd-smp@freebsd.org; Thu, 17 Jun 2004 11:38:21 +0300 Date: Thu, 17 Jun 2004 11:41:04 +0300 From: Ostash! X-Mailer: The Bat! (v2.04.7) X-Priority: 3 (Normal) Message-ID: <541854622.20040617114104@ukrpost.net> To: freebsd-smp@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-u Content-Transfer-Encoding: 8bit Subject: Panic while initialising SMP X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Ostash! List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2004 08:42:02 -0000 Прив╕т freebsd-smp! I got the following with FreeBSD-4.10 RELEASE on dual Xeon 2.4Ghz: ================================================================================= Copyright (c) 1992-2884 The FreeBSD Project Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.10-RELEASE #0: Tue Jun 15 88:14:24 MSD 2004 root@****.*******.***:/usr/obj/usr/src/sys/BIZ Timecounter "i8254" frequency 1193182 Hz CPU: Intel(R) Xeon(TH) CPU 2.40GHz (2392.04-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 1073217536 (1048064K bytes) avail memory = 1041129472 (1016728K bytes) Programing 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programing 24 pins in IOAPIC #1 Programing 24 pins in IOAPIC #2 AP #3 (PHY# 7) failed! panic y/n? [y] panic: bye-bye mp_lock = 00000001; cpuid = 0; lapic.id = 00000000 Uptime: 0s ================================================================================= Any ideas? Is it fixed in 5.2? Усього найкращого, Ostash! np: Metallica & Symphony - The Call Of The Ktulu ... [Team Гарячi севастопольськi дiвчата] [Team Укра╖нська мова] --- The Bat! 2.04.7 Windows 2000 5.0.2195 Service Pack 4 * Origin: За деньги нельзя купить друга, зато можно приобрести врагов поприличней (osspam@ukrpost.net)