From owner-freebsd-smp Sun Nov 21 5:25:30 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mail.rdc3.on.home.com (ha1.rdc3.on.home.com [24.2.9.68]) by hub.freebsd.org (Postfix) with ESMTP id DF3401519E for ; Sun, 21 Nov 1999 05:25:25 -0800 (PST) (envelope-from nemesys@home.com) Received: from cr717730b ([24.112.177.211]) by mail.rdc3.on.home.com (InterMail v4.01.01.02 201-229-111-106) with SMTP id <19991121132328.BXEA7575.mail.rdc3.on.home.com@cr717730b>; Sun, 21 Nov 1999 05:23:28 -0800 Message-ID: <002c01bf3423$b22f3080$d3b17018@wlfdle1.on.wave.home.com> From: "Jason Craig" To: "FreeBSD SMP" Cc: "Matthew N. Dodd" Subject: panic: APIC RTC != 8 Date: Sun, 21 Nov 1999 08:24:10 -0500 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey folks, I am having a bit of a problem compiling a new SMP kernel for this dual proc IBM PC Server 320. I have been working with Matthew on the MCA support of this machine, and it boots fine with a single proc kernel. Here's what I see when I try and boot with the multi proc kernel: lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 panic: APIC RTC != 8 mp_lock = 00000002; cpuid = 0; lapic.id = 00000000 syncing disks... done Automatic reboot in 15 seconds - press a key on the console to abort Mathew mentioned I should also include a dump of my mptable. Here it is: ============================================================================ === MPTable, version 2.0.15 ---------------------------------------------------------------------------- --- MP Floating Pointer Structure: location: EBDA physical address: 0x0009f1e0 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0xb9 mode: Virtual Wire ---------------------------------------------------------------------------- --- MP Config Table Header: physical address: 0x0009f1f0 signature: 'PCMP' base table length: 276 version: 1.1 checksum: 0x60 OEM ID: 'IBM ' Product ID: '8640 PCI/MCA' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 26 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 ---------------------------------------------------------------------------- --- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x10 BSP, usable 5 2 5 0x03bf 1 0x10 AP, usable 5 2 5 0x03bf -- Bus: Bus ID Type 0 PCI 1 MCA 2 ISA -- I/O APICs: APIC ID Version State Address 2 0x10 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 1 0 2 0 INT active-hi edge 1 1 2 1 INT active-hi edge 1 0 2 2 INT active-lo level 1 3 2 3 INT active-lo level 1 4 2 4 INT active-lo level 1 5 2 5 INT active-lo level 1 6 2 6 INT active-hi level 1 7 2 7 INT active-hi edge 1 8 2 8 INT active-lo level 1 9 2 9 INT active-lo level 1 10 2 10 INT active-lo level 1 11 2 11 INT active-hi edge 1 12 2 12 INT active-lo edge 1 13 2 13 INT active-lo level 1 14 2 14 INT active-lo level 1 15 2 15 INT active-lo level 0 4:A 2 15 INT active-lo level 0 12:A 2 11 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 0 0:A 255 0 NMI active-hi edge 0 0:A 255 1 ---------------------------------------------------------------------------- --- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optional (built-in defaults will work in most cases): #options NCPU=2 # number of CPUs #options NBUS=3 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs ============================================================================ === When I configured my kernel, I used the following: # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): options NCPU=2 # number of CPUs options NBUS=4 # number of busses options NAPIC=1 # number of IO APICs options NINTR=24 # number of INTs Any thoughts on this problem? Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 21 9:24:57 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by hub.freebsd.org (Postfix) with ESMTP id 17FE614D34 for ; Sun, 21 Nov 1999 09:24:53 -0800 (PST) (envelope-from watchman@ludd.luth.se) Received: from ludd.luth.se (d212-151-108-60.swipnet.se [212.151.108.60]) by mb04.swip.net (8.8.8/8.8.8) with ESMTP id SAA25380 for ; Sun, 21 Nov 1999 18:24:31 +0100 (MET) Message-ID: <38382B5D.9138E103@ludd.luth.se> Date: Sun, 21 Nov 1999 18:26:53 +0100 From: Jag Organization: Acne X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.3-STABLE i386) X-Accept-Language: en-US MIME-Version: 1.0 To: freebsd-smp@FreeBSD.ORG Subject: QuakeIII Test on 3.3 STABLE? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! Has anybody with a fast connection and a 3.3 SMP system tried the new, hot Q3 Test? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Nov 21 9:44:32 1999 Delivered-To: freebsd-smp@freebsd.org Received: from drago.cert.org.tw (drago.cert.org.tw [140.117.100.10]) by hub.freebsd.org (Postfix) with ESMTP id C890214BF8 for ; Sun, 21 Nov 1999 09:44:29 -0800 (PST) (envelope-from foxfair@drago.cert.org.tw) Received: from foxfair (chateau.cert.org.tw [140.117.100.101]) by drago.cert.org.tw (8.9.3/8.9.3) with SMTP id BAA79892; Mon, 22 Nov 1999 01:41:24 +0800 (CST) (envelope-from foxfair@drago.cert.org.tw) Date: Mon, 22 Nov 1999 01:50:43 +0800 From: Foxfair Hu To: Jag Cc: freebsd-smp@FreeBSD.org Subject: Re: QuakeIII Test on 3.3 STABLE? In-Reply-To: <38382B5D.9138E103@ludd.luth.se> References: <38382B5D.9138E103@ludd.luth.se> Message-Id: <383830F326C.26B7FOXFAIR@drago.cert.org.tw> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.25.04 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 21 Nov 1999 18:26:53 +0100 Jag wrote: > Hi! > > Has anybody with a fast connection and a 3.3 SMP system tried the new, > hot Q3 Test? > AFAIK, q3demoTEST(the latest beta version of Q3Arena) has no support on SMP yet, so it is not the smp issue. But yes, I can run a linuxquake3 under FreeBSD's amazing linux-emu env(thanks! marcel), and this server is a dual-celeron FreeBSD box. I'm waiting for id-software to support smp function too. > > 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 Sun Nov 21 20:38:43 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mail.rdc3.on.home.com (ha1.rdc3.on.home.com [24.2.9.68]) by hub.freebsd.org (Postfix) with ESMTP id A024214A07 for ; Sun, 21 Nov 1999 20:38:40 -0800 (PST) (envelope-from nemesys@home.com) Received: from cr717730b ([24.112.177.211]) by mail.rdc3.on.home.com (InterMail v4.01.01.02 201-229-111-106) with SMTP id <19991122043642.PKKQ7575.mail.rdc3.on.home.com@cr717730b> for ; Sun, 21 Nov 1999 20:36:42 -0800 Message-ID: <001101bf34a3$4a67e660$d3b17018@wlfdle1.on.wave.home.com> From: "Jason Craig" To: "FreeBSD SMP" Subject: IRQ sharing in SMP? Date: Sun, 21 Nov 1999 23:37:32 -0500 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I posted a message earlier today on my problem, and have done a little further checking on it. In my mptable dump I found two entries that were using IRQ11. Is this normal? Or even allowed? ----- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 1 0 2 0 INT active-hi edge 1 1 2 1 INT active-hi edge 1 0 2 2 INT active-lo level 1 3 2 3 INT active-lo level 1 4 2 4 INT active-lo level 1 5 2 5 INT active-lo level 1 6 2 6 INT active-hi level 1 7 2 7 INT active-hi edge 1 8 2 8 INT active-lo level 1 9 2 9 INT active-lo level 1 10 2 10 INT active-lo level 1 11 2 11 <======= ??? INT active-hi edge 1 12 2 12 INT active-lo edge 1 13 2 13 INT active-lo level 1 14 2 14 INT active-lo level 1 15 2 15 INT active-lo level 0 4:A 2 15 INT active-lo level 0 12:A 2 11 <======= ??? -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 0 0:A 255 0 NMI active-hi edge 0 0:A 255 1 ----- Here's where I think it gets more interesting. The SMP kernel I compiled was crapping out with the following: ----- lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 panic: APIC RTC != 8 mp_lock = 00000002; cpuid = 0; lapic.id = 00000000 syncing disks... done Automatic reboot in 15 seconds - press a key on the console to abort ----- I then checked my other kernel which is the same, just without SMP support. In the single processor kernel, it continues after ppi0: and goes to the SCSI routines. The multi processor kernel dies at this point. What is funny is that ahc0 is using IRQ 11, the same IRQ that mptable has two entries for. Coincidence? I've also been looking around as to what it means by APIC RTC != 8. Whats not equal to 8? :) ----- ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 6.0 on pci0 isa0: on isab0 chip1: at device 8.0 on pci0 vga-pci0: irq 0 at device 10.0 on pci0 ahc0: irq 11 at device 12.0 on pci0 ahc0: aic7870 Wide Channel A, SCSI Id=7, 16/255 SCBs eisa0: on motherboard mainboard0: on eisa0 slot 0 ----- lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 Waiting 15 seconds for SCSI devices to settle Creating DISK da0 Creating DISK da1 Creating DISK da2 Creating DISK da3 sa0 at ahc0 bus 0 target 2 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 7.812MB/s transfers (7.812MHz, offset 15) Creating DISK cd0 da0 at ahc0 bus 0 target 0 lun 0 ------ Your help would be appreciated. Thanks, Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Nov 22 7:51: 5 1999 Delivered-To: freebsd-smp@freebsd.org Received: from relay05.indigo.ie (relay05.indigo.ie [194.125.133.229]) by hub.freebsd.org (Postfix) with SMTP id 8072014CF4 for ; Mon, 22 Nov 1999 07:50:58 -0800 (PST) (envelope-from judgea@indigo.ie) Received: (qmail 18300 messnum 1192130 invoked from network[194.125.133.235/relay-mgr.indigo.ie]); 22 Nov 1999 15:50:37 -0000 Received: from relay-mgr.indigo.ie (HELO indigo.ie) (194.125.133.235) by relay05.indigo.ie (qp 18300) with SMTP; 22 Nov 1999 15:50:37 -0000 To: freebsd-hardware@freebsd.org, freebsd-smp@freebsd.org Subject: Re: Seeking recommendations/stories for big servers In-reply-to: Message from Joerg Micheel dated Wednesday at 18:24. From: Alan Judge Date: Mon, 22 Nov 1999 15:50:37 +0000 Message-Id: <19991122155059.8072014CF4@hub.freebsd.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Joerg> I'd be interested to hear some experience/stories from people running Joerg> such systems. I can't really comment on the SMP issue, but we've been quite happy with the Dell servers (4350 and 2300s mostly). Fast, run FreeBSD well, with good LVD SCSI drives, the I/O screams. Dell do nice rack mount servers up to 8 processor. An 8450 with the 64-bit Adaptec 3950U2W cards and external shelves of LVD drives would probably fly. Alternatively, though I haven't tried it, fibre channel with the Qlogic cards might work better. It depends what you are optimising for. Dell do nice external disk shelves, but I have little experience with them; we use Network Appliance filers for all our large storage needs, something you might also consider, depending on what you want and can afford. We did have problems with SMP hangs in stable a while back, but I haven't tested in a while (we only use UP boxes in production, so the SMP stuff is just for testing). Given that FreeBSD still uses a single big lock for the kernel, your applications would need to be very CPU intensive to make much use of lots of processors. An I/O loaded application might be just as fast on a single processor box. I've had bad experiences with Compaq kit being non-standard in the past, but the Digital stuff might be OK. Joerg> I'm also interested about network-fanout stories. We may Joerg> NFS-mount the server and have a 100MBit Ethernet box behind it Joerg> for access from a farm of PCs. The Intel PRO/100 cards are great for 100Mb, but almost any of the Dell boxes will easily max one out for NFS and file transfers. You might want to consider either Gigabit ethernet or multiple 100Mb cards if you want really fast access from lots of clients. -- Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 3:34:36 1999 Delivered-To: freebsd-smp@freebsd.org Received: from yyy.or.jp (host03.interwave.or.jp [202.214.252.3]) by hub.freebsd.org (Postfix) with SMTP id BC80D14C0D for ; Tue, 23 Nov 1999 03:34:33 -0800 (PST) (envelope-from hnokubi@yyy.or.jp) Received: (qmail 7413 invoked from network); 23 Nov 1999 20:33:32 +0900 Received: from urayasu118.interwave.or.jp (HELO ppp-client.yyy.or.jp) (210.138.157.154) by mail.yyy.or.jp with SMTP; 23 Nov 1999 20:33:32 +0900 Received: from sassaby.nokubi.or.jp (sassaby [192.168.9.3]) by ppp-client.yyy.or.jp (8.9.1/3.5Wpl7-ppp) with ESMTP id UAA15792 for ; Tue, 23 Nov 1999 20:34:57 +0900 (JST) Received: from sassaby.nokubi.or.jp (localhost.nokubi.or.jp [127.0.0.1]) by sassaby.nokubi.or.jp (8.9.3/3.5Wpl7-glove) with ESMTP id UAA00588 for ; Tue, 23 Nov 1999 20:34:52 +0900 (JST) To: freebsd-smp@freebsd.org Subject: location of MP Configuration Table on NEC PC98 Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 23 Nov 1999 20:34:52 +0900 From: NOKUBI Hirotaka Message-Id: <19991123113434.BC80D14C0D@hub.freebsd.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm developping NEC PC98 version of FreeBSD (we call it FreeBSD(98)) together with KATO-san, TAKAHASHI-san. There are some SMP model PC98, and I found that FreeBSD(98) with some modification can run on these as well as Windows NT. But, because MP Configuration Table is placed at the top of system physical memory, current FreeBSD implementation can't handle it. It comforms to Multiprocessor Specification V.1.4, if FreeBSD could handle this, we would be very happy. Is it possible to change implementation? My idea is like this. In the current implementation, pmap_bootstrap() refers cpu_apic_address, so mptable_pass1() needs to be called before that. It could be better that the procedure which maps APIC to virtual space is a function, say mp_map_apic(), not a part of pmap_bootstrap(). Then, mptable_pass1() can use CMAP[12] to read MP Configuration Table at the top of system physical memory. ---- NOKUBI Hirotaka Fingerprint20 = DEBC 0793 7CD6 92F1 0A1F A792 9E2F EEEE A41B 171D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 5:41:56 1999 Delivered-To: freebsd-smp@freebsd.org Received: from web113.yahoomail.com (web113.yahoomail.com [205.180.60.84]) by hub.freebsd.org (Postfix) with SMTP id 8A2A0150C9 for ; Tue, 23 Nov 1999 05:41:53 -0800 (PST) (envelope-from thallgren@yahoo.com) Message-ID: <19991123134010.5851.rocketmail@web113.yahoomail.com> Received: from [195.163.91.180] by web113.yahoomail.com; Tue, 23 Nov 1999 05:40:10 PST Date: Tue, 23 Nov 1999 05:40:10 -0800 (PST) From: =?iso-8859-1?q?Tommy=20Hallgren?= Subject: Matt's new unlock optimiazation To: freebsd-smp@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi subscribers! FYI, this popped up in the linux-kern mailing-list: http://boudicca.tux.org/hypermail/linux-kernel/this-week/0060.html The entire thread is here: http://boudicca.tux.org/hypermail/linux-kernel/this-week/subject.html#start The subject is: spin_unlock optimization(i386) Regards, Tommy ===== Tommy Hallgren Briljantg. 31, SE-421 49, Göteborg Tel.: 0709 - 312 404 (GSM) Tel.: 031 - 47 65 28 (Home) __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 6: 2:32 1999 Delivered-To: freebsd-smp@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 9450F1503C for ; Tue, 23 Nov 1999 06:02:27 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 3A7D41C6D; Tue, 23 Nov 1999 22:01:28 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Tommy Hallgren Cc: freebsd-smp@freebsd.org Subject: Re: Matt's new unlock optimiazation In-Reply-To: Message from Tommy Hallgren of "Tue, 23 Nov 1999 05:40:10 PST." <19991123134010.5851.rocketmail@web113.yahoomail.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Tue, 23 Nov 1999 22:01:28 +0800 From: Peter Wemm Message-Id: <19991123140128.3A7D41C6D@overcee.netplex.com.au> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tommy Hallgren wrote: > Hi subscribers! > > FYI, this popped up in the linux-kern mailing-list: > http://boudicca.tux.org/hypermail/linux-kernel/this-week/0060.html > > The entire thread is here: > http://boudicca.tux.org/hypermail/linux-kernel/this-week/subject.html#start > > The subject is: spin_unlock optimization(i386) A bit worrying, to say the least, especially coming from Linus (even moreso in light of his work at transmeta and what they're doing with/to Intel cpu's). Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 6:11:24 1999 Delivered-To: freebsd-smp@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id B4465152DD for ; Tue, 23 Nov 1999 06:11:18 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id PAA28650; Tue, 23 Nov 1999 15:09:59 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Peter Wemm Cc: Tommy Hallgren , freebsd-smp@FreeBSD.ORG Subject: Re: Matt's new unlock optimiazation In-reply-to: Your message of "Tue, 23 Nov 1999 22:01:28 +0800." <19991123140128.3A7D41C6D@overcee.netplex.com.au> Date: Tue, 23 Nov 1999 15:09:59 +0100 Message-ID: <28648.943366199@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19991123140128.3A7D41C6D@overcee.netplex.com.au>, Peter Wemm writes : >Tommy Hallgren wrote: >> Hi subscribers! >> >> FYI, this popped up in the linux-kern mailing-list: >> http://boudicca.tux.org/hypermail/linux-kernel/this-week/0060.html >> >> The entire thread is here: >> http://boudicca.tux.org/hypermail/linux-kernel/this-week/subject.html#start >> >> The subject is: spin_unlock optimization(i386) > >A bit worrying, to say the least, especially coming from Linus (even moreso >in light of his work at transmeta and what they're doing with/to Intel cpu's). We (Peter and I :-) actually have been there once before, in what '96 or '97 when we got SMP on its legs. I didn't comment on Matts stuff because I didn't want to upset him, but I agree with Linus: This doesn't work unless other serialization is added to the code. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 9: 3:44 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 79FB514C4F for ; Tue, 23 Nov 1999 09:03:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA09896; Tue, 23 Nov 1999 09:03:00 -0800 (PST) (envelope-from dillon) Date: Tue, 23 Nov 1999 09:03:00 -0800 (PST) From: Matthew Dillon Message-Id: <199911231703.JAA09896@apollo.backplane.com> To: Peter Wemm Cc: Tommy Hallgren , freebsd-smp@FreeBSD.ORG Subject: Re: Matt's new unlock optimiazation References: <19991123140128.3A7D41C6D@overcee.netplex.com.au> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> The entire thread is here: :> http://boudicca.tux.org/hypermail/linux-kernel/this-week/subject.html#start :> :> The subject is: spin_unlock optimization(i386) : :A bit worrying, to say the least, especially coming from Linus (even moreso :in light of his work at transmeta and what they're doing with/to Intel cpu's). : :Cheers, :-Peter hmm. I was under the impression that the Pentium serialized writes by reserving locations through their caches. But knowing Intel, Linus is probably right. Sometimes I wish I could just take a gun to the Pentium. But this isn't a big deal, we should simply be able to do a locked write into the per-cpu area to synchronize just before we release the lock. This is still going to be a whole lot more efficient then trying to lock a write to the shared lock, because we will almost certainly already own that memory location. I'll run some tests and commit a solution Nobody commit anything. No matter what, we still get the benefit of the recursion lock optimization which is actually the more important one. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 9:52:25 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 329BA14C05 for ; Tue, 23 Nov 1999 09:52:15 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA10135; Tue, 23 Nov 1999 09:51:29 -0800 (PST) (envelope-from dillon) Date: Tue, 23 Nov 1999 09:51:29 -0800 (PST) From: Matthew Dillon Message-Id: <199911231751.JAA10135@apollo.backplane.com> To: Peter Wemm , Tommy Hallgren , freebsd-smp@FreeBSD.ORG Subject: more on... Re: Matt's new unlock optimiazation References: <19991123140128.3A7D41C6D@overcee.netplex.com.au> <199911231703.JAA09896@apollo.backplane.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ::> ::> The subject is: spin_unlock optimization(i386) :: ::A bit worrying, to say the least, especially coming from Linus (even moreso ::in light of his work at transmeta and what they're doing with/to Intel cpu's). :: ::Cheers, ::-Peter : : hmm. I was under the impression that the Pentium serialized writes : by reserving locations through their caches. But knowing Intel, Linus : is probably right. : : Sometimes I wish I could just take a gun to the Pentium. : : But this isn't a big deal, we should simply be able to do a locked : write into the per-cpu area to synchronize just before we release : the lock. This is still going to be a whole lot more efficient then : trying to lock a write to the shared lock, because we will almost certainly : already own that memory location. : : I'll run some tests and commit a solution Nobody commit anything. No : matter what, we still get the benefit of the recursion lock optimization : which is actually the more important one. Ok, there's a problem but I don't believe you have to use a locked instruction to get around it. All you should need to do is synchronize the instruction stream. I remember from somewhere that 'NOP' (which is really just and xchg instruction) does this. But I am not sure, I am going to have to do some more research. I did test and am correct about the cache line ownership change overhead. On an SMP box, with two competing processors, using a locked instruction on the *same* physical memory location results in 3x the overhead whereas the same locked instruction on different memory locations are more efficient. So if I can't find a definitive way to do instruction synchronization, we will simply do a dummy locked instruction into the per-cpu area. With cmpxchgl test3:/home/dillon# ./lock shared 165 nS/loop test3:/home/dillon# ./lock private 53 nS/loop With just xchgl test3:/home/dillon# ./lock shared 160 nS/loop test3:/home/dillon# ./lock private 47 nS/loop -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 10:20:26 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0572A14A04 for ; Tue, 23 Nov 1999 10:20:12 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA10294; Tue, 23 Nov 1999 10:19:03 -0800 (PST) (envelope-from dillon) Date: Tue, 23 Nov 1999 10:19:03 -0800 (PST) From: Matthew Dillon Message-Id: <199911231819.KAA10294@apollo.backplane.com> To: Matthew Dillon Cc: Peter Wemm , Tommy Hallgren , freebsd-smp@FreeBSD.ORG Subject: Found it ... Re: Matt's new unlock optimiazation References: <19991123140128.3A7D41C6D@overcee.netplex.com.au> <199911231703.JAA09896@apollo.backplane.com> <199911231751.JAA10135@apollo.backplane.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I got it. http://developer.intel.com/drg/pentiumii/appnotes/831.htm All we need is a serializing instruction. CPUID will do the trick, but actually doing a locked instruction on private memory (verses shared memory) is going to be faster. with cpuid 141 ns lock/private 47 ns (same with or without segment override) lock/shared 160 ns (with cpu contention) I'll commit the change in a little bit. It will look a little ugly, but it will be very fast. BTW, if people want to mess with this, my test program is below. -Matt cc lock1.c lock2.s -o test /* * LOCK1.C */ #include #include #include #include #include #include #include #include #define LOOPS 4000000 extern void fubar(void *ptr); int main(int ac, char **av) { int i; int dt; void *ptr; struct timeval tv1; struct timeval tv2; int flags = MAP_ANON; if (ac == 1) { printf("%s [shared/private]\n", av[0]); exit(1); } if (strcmp(av[1], "shared") == 0) { flags |= MAP_SHARED; } else if (strcmp(av[1], "private") == 0) { ; } else { printf("illegal argument\n"); exit(1); } ptr = mmap(NULL, getpagesize(), PROT_READ|PROT_WRITE, flags, -1, 0); gettimeofday(&tv1, NULL); if (fork() == 0) { for (i = 0; i < LOOPS; ++i) fubar(ptr); _exit(0); } else { for (i = 0; i < LOOPS; ++i) fubar(ptr); while (wait(NULL) > 0) ; } gettimeofday(&tv2, NULL); dt = tv2.tv_usec + 1000000 - tv1.tv_usec + (tv2.tv_sec - tv1.tv_sec - 1) * 1000000; printf("%d nS/loop\n", dt * 1000 / (LOOPS * 2)); return(0); } /* * LOCK2.S */ .text .globl fubar fubar: movl 4(%esp),%ecx /*cpuid*/ /*lock; cmpxchgl %eax,(%ecx)*/ /*lock; xchg %eax,(%ecx)*/ ret To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 10:23:42 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 96D641532E for ; Tue, 23 Nov 1999 10:23:33 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA10338; Tue, 23 Nov 1999 10:23:24 -0800 (PST) (envelope-from dillon) Date: Tue, 23 Nov 1999 10:23:24 -0800 (PST) From: Matthew Dillon Message-Id: <199911231823.KAA10338@apollo.backplane.com> To: Peter Wemm , Tommy Hallgren , freebsd-smp@FreeBSD.ORG Subject: Re: Found it ... Re: Matt's new unlock optimiazation References: <19991123140128.3A7D41C6D@overcee.netplex.com.au> <199911231703.JAA09896@apollo.backplane.com> <199911231751.JAA10135@apollo.backplane.com> <199911231819.KAA10294@apollo.backplane.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : All we need is a serializing instruction. CPUID will do the trick, but : actually doing a locked instruction on private memory (verses shared : memory) is going to be faster. : with cpuid XXXXXXXX ns <--- change to 13 : lock/private 47 ns (same with or without segment override) : lock/shared 160 ns (with cpu contention) Oops, correction. cpuid is fastest -- 13 ns. I had mistakenly turned on two of the tests in the assembly. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 10:24:21 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 620CE15138 for ; Tue, 23 Nov 1999 10:24:18 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA10344; Tue, 23 Nov 1999 10:24:11 -0800 (PST) (envelope-from dillon) Date: Tue, 23 Nov 1999 10:24:11 -0800 (PST) From: Matthew Dillon Message-Id: <199911231824.KAA10344@apollo.backplane.com> To: Peter Wemm , Tommy Hallgren , freebsd-smp@FreeBSD.ORG Subject: Re: Found it ... Re: Matt's new unlock optimiazation References: <19991123140128.3A7D41C6D@overcee.netplex.com.au> <199911231703.JAA09896@apollo.backplane.com> <199911231751.JAA10135@apollo.backplane.com> <199911231819.KAA10294@apollo.backplane.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : with cpuid 141 ns : lock/private 47 ns (same with or without segment override) : lock/shared 160 ns (with cpu contention) Argg. No, I was right the first time. Too many open vi's on the same file :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 10:41:25 1999 Delivered-To: freebsd-smp@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 9F83415462 for ; Tue, 23 Nov 1999 10:40:09 -0800 (PST) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id MAA01232; Tue, 23 Nov 1999 12:38:47 -0600 (CST) Date: Tue, 23 Nov 1999 12:38:46 -0600 From: Alan Cox To: Poul-Henning Kamp Cc: Peter Wemm , Tommy Hallgren , freebsd-smp@freebsd.org Subject: Re: Matt's new unlock optimiazation Message-ID: <19991123123846.E20514@cs.rice.edu> References: <19991123140128.3A7D41C6D@overcee.netplex.com.au> <28648.943366199@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: <28648.943366199@critter.freebsd.dk>; from Poul-Henning Kamp on Tue, Nov 23, 1999 at 03:09:59PM +0100 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What Linus says is definitely true of non-x86 architectures, such as Alpha, but I had thought (not to be confused with "know for a fact") that the x86 was "sequentially consistent", making Matt's optimization legal. I've definitely seen the statement in the Intel manuals that writes are not reordered. Thus, if the program on processor 1 writes X to location A followed by Y to location B, then processor 2 is guaranteed to see X in A (and not some old value) if it's seen Y in B. Suppose that B is our spinlock and Y is the value that indicates the lock is available/unlocked. If I'm able to determine that the lock is available, then I'm guaranteed to see any changes written before the unlock. Before the general area of "memory consistency" models (not to be confused with cache coherence) was widely understood by architects, there were some optimizations, such as delaying the application of cache line invalidation directives from the bus, that broke sequential consistency without people realizing it. I had presumed that the x86 got this right. Alan P.S. If this distinction between "memory consistency" models and cache coherence (protocols) sounds a bit strange, think of it this way: the cache coherence protocol governs what happens when two processors are modifying the same cache line and the memory consistency model deals with the ordering of modifications to different cache lines. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 11: 1:28 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D87D51535E for ; Tue, 23 Nov 1999 11:01:25 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA10726; Tue, 23 Nov 1999 11:01:00 -0800 (PST) (envelope-from dillon) Date: Tue, 23 Nov 1999 11:01:00 -0800 (PST) From: Matthew Dillon Message-Id: <199911231901.LAA10726@apollo.backplane.com> To: Alan Cox Cc: Poul-Henning Kamp , Peter Wemm , Tommy Hallgren , freebsd-smp@FreeBSD.ORG Subject: Re: Matt's new unlock optimiazation References: <19991123140128.3A7D41C6D@overcee.netplex.com.au> <28648.943366199@critter.freebsd.dk> <19991123123846.E20514@cs.rice.edu> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :What Linus says is definitely true of non-x86 architectures, :such as Alpha, but I had thought (not to be confused with :"know for a fact") that the x86 was "sequentially :consistent", making Matt's optimization legal. : :I've definitely seen the statement in the Intel manuals :that writes are not reordered. Thus, if the :program on processor 1 writes X to location A followed :by Y to location B, then processor 2 is guaranteed to :see X in A (and not some old value) if it's seen Y in B. Yes, that's what I thought too. Writes are not reordered, but remember that pentiums do speculative reads and out of order instruction execution as well. Apparently pentiums also do write buffering (rather then write to the cache synchronously). http://developer.intel.com/drg/pentiumii/appnotes/831.htm The above says: * writes are ordered * reads do not pass *conflicting* writes, which means they can pass non-conflicting writes. BROKEN!!!!!!! * Instructions may execute out of order (if non conflicting) * Writes can be buffered -- that is, the pending writes are pending going INTO the cache and not synchronously written to the cache as they are on, say, the later MIPS cpus. What a grade-A screwup by Intel. Extremely annoying at the very least. Gimme a MIPS chip any day. In anycase, I've committed the change. It only adds 50ns or so to the release code and then only on the final release. The app note says: * Locked operations wait for all previous instructions to complete. They wait for on-chip buffers to drain, and for external buffers to be emptied. * Locked operations synchronize data, but not instruction fetch or TLB miss handling. Data may be present in a cache or TLB, due to the speculative cacheability feature, which means that a lock cannot be used to prevent data from being fetched into a cache or TLB. I believe this does what we want. In regards to the last bit, since the cache is operating under SMP protocols the speculative read into the cache should be ok as long as the cpu's buffers have been drained, which they have been. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 11:36:19 1999 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 E82A414BEE for ; Tue, 23 Nov 1999 11:36:14 -0800 (PST) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id MAA11820; Tue, 23 Nov 1999 12:02:01 -0800 (PST) Date: Tue, 23 Nov 1999 12:02:01 -0800 (PST) From: Alfred Perlstein To: Matthew Dillon Cc: Alan Cox , Poul-Henning Kamp , Peter Wemm , Tommy Hallgren , freebsd-smp@FreeBSD.ORG Subject: Re: Matt's new unlock optimiazation In-Reply-To: <199911231901.LAA10726@apollo.backplane.com> 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 Tue, 23 Nov 1999, Matthew Dillon wrote: > :What Linus says is definitely true of non-x86 architectures, > :such as Alpha, but I had thought (not to be confused with > :"know for a fact") that the x86 was "sequentially > :consistent", making Matt's optimization legal. > : > :I've definitely seen the statement in the Intel manuals > :that writes are not reordered. Thus, if the > :program on processor 1 writes X to location A followed > :by Y to location B, then processor 2 is guaranteed to > :see X in A (and not some old value) if it's seen Y in B. > > Yes, that's what I thought too. Writes are not reordered, > but remember that pentiums do speculative reads and out of > order instruction execution as well. Apparently pentiums also > do write buffering (rather then write to the cache synchronously). > > http://developer.intel.com/drg/pentiumii/appnotes/831.htm > > The above says: > > * writes are ordered > > * reads do not pass *conflicting* writes, which means they > can pass non-conflicting writes. BROKEN!!!!!!! > > * Instructions may execute out of order (if non conflicting) > > * Writes can be buffered -- that is, the pending writes > are pending going INTO the cache and not synchronously > written to the cache as they are on, say, the later MIPS cpus. > > What a grade-A screwup by Intel. Extremely annoying at the very least. > Gimme a MIPS chip any day. I'm a bit confused by this, I take it to mean that there's really nothing wrong with the lock behavior however, if there are outstanding memory transactions to handle then they may actually be done after we've released the lock by the CPU that's released it. And that those memory operations rely on the mutual exclusion of the lock, so basically you have this sort of window: CPU a (has lock) CPU b (wants lock) mem write A mem read B mem write C RELEASE lock GOT lock A, B C aren't garanteed to be complete at this point and could be committed to memory at any point following the lock release? Is that correct? -Alfred (who still needs his morning pot of coffee) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 11:42:57 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 7FFF41539C for ; Tue, 23 Nov 1999 11:42:55 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA11156; Tue, 23 Nov 1999 11:42:11 -0800 (PST) (envelope-from dillon) Date: Tue, 23 Nov 1999 11:42:11 -0800 (PST) From: Matthew Dillon Message-Id: <199911231942.LAA11156@apollo.backplane.com> To: Alfred Perlstein Cc: Alan Cox , Poul-Henning Kamp , Peter Wemm , Tommy Hallgren , freebsd-smp@FreeBSD.ORG Subject: Re: Matt's new unlock optimiazation References: Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :I'm a bit confused by this, I take it to mean that there's really :nothing wrong with the lock behavior however, if there are outstanding :memory transactions to handle then they may actually be done after :we've released the lock by the CPU that's released it. : :And that those memory operations rely on the mutual exclusion of :the lock, so basically you have this sort of window: : : CPU a (has lock) CPU b (wants lock) : : mem write A : mem read B : mem write C : RELEASE lock There is only one sequence of events that I believe can cause a problem, at least from my read of the app note: mem read A RELEASE lock (mem write X) In this case the instruction that runs 'mem read A' may be executed out of order from the instruction which writes X. Since location A does not conflict with the address of the lock, Intel's current spec allows the out of order execution to occur. I'm not sure how intel's speculative read works. They seem to imply that it goes into the cache, in which case cache coherency protocols will prevent a conflict. But if it goes into the execution unit's data buffer or if the instructions are actually executed out of order, we have a problem. Intel says that writes are ordered, so pending writes prior to release will not be a problem (no need for a locked instruction). We are left with mixed reads and writes. No sense taking any chances, it only costs us 55nS (on a P3-450). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 11:51:24 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 8810414BC4 for ; Tue, 23 Nov 1999 11:51:12 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA11203; Tue, 23 Nov 1999 11:51:02 -0800 (PST) (envelope-from dillon) Date: Tue, 23 Nov 1999 11:51:02 -0800 (PST) From: Matthew Dillon Message-Id: <199911231951.LAA11203@apollo.backplane.com> To: Alfred Perlstein Cc: Alan Cox , Poul-Henning Kamp , Peter Wemm , Tommy Hallgren , freebsd-smp@FreeBSD.ORG Subject: Re: Matt's new unlock optimiazation References: Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : mem write A : mem read B : mem write C : RELEASE lock : GOT lock : : A, B C aren't garanteed : to be complete at this point : and could be committed to : memory at any point following : the lock release? The key thing to focus on here is the pentium's multiple execution units. We actually don't care when main memory is read or written, only when the execution units read or write the L2 cache relative to the execution of other instructions (The L2 cache operates under an SMP cache coherency protocol). Since there are multiple execution units we have to depend on Intel's rules for allowing out of order execution to determine whether a problem exists or not. In this case a problem does exist in a very small window due to Intel potentially allowing a read+write (or write+read) to be executed out of order, at least according to their documentation. I don't think the original code had a problem since it ran enough instructions to clear the pipeline and issued a write-APIC write-unlock rather then read+write or write+read, and write ordering is guarenteed, but you have to ask yourself if you trust Intel that far and the answer, at least for me, is "no". -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 12:24:17 1999 Delivered-To: freebsd-smp@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 07029153CD for ; Tue, 23 Nov 1999 12:23:59 -0800 (PST) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id OAA05564; Tue, 23 Nov 1999 14:22:54 -0600 (CST) Date: Tue, 23 Nov 1999 14:22:53 -0600 From: Alan Cox To: Alfred Perlstein Cc: Matthew Dillon , Poul-Henning Kamp , Peter Wemm , Tommy Hallgren , freebsd-smp@freebsd.org Subject: Re: Matt's new unlock optimiazation Message-ID: <19991123142253.M27120@cs.rice.edu> References: <199911231901.LAA10726@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: ; from Alfred Perlstein on Tue, Nov 23, 1999 at 12:02:01PM -0800 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I would *strongly* recommend that everyone interested in low-level SMP issues read http://rsim.cs.uiuc.edu/~sadve/Publications/models_tutorial.ps. This is a tutorial on memory consistency models (with lots of examples) from IEEE Computer. The Intel note that Matt referred to describes a lot of detail about the model implemented by the x86, but in the end says, for all practical purposes, you should treat the x86 as though it implements processor-ordering (or processor consistency). The tutorial explains precisely what this means to you as a programmer. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 12:43: 7 1999 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 0FD0F14C4F for ; Tue, 23 Nov 1999 12:43:05 -0800 (PST) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id NAA13577; Tue, 23 Nov 1999 13:09:44 -0800 (PST) Date: Tue, 23 Nov 1999 13:09:44 -0800 (PST) From: Alfred Perlstein To: Alan Cox Cc: Matthew Dillon , Poul-Henning Kamp , Peter Wemm , Tommy Hallgren , freebsd-smp@freebsd.org Subject: Re: Matt's new unlock optimiazation In-Reply-To: <19991123142253.M27120@cs.rice.edu> 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 Tue, 23 Nov 1999, Alan Cox wrote: > I would *strongly* recommend that everyone interested in low-level SMP > issues read http://rsim.cs.uiuc.edu/~sadve/Publications/models_tutorial.ps. > This is a tutorial on memory consistency models (with lots > of examples) from IEEE Computer. > > The Intel note that Matt referred to describes a lot of detail > about the model implemented by the x86, but in the end says, > for all practical purposes, you should treat the x86 as though > it implements processor-ordering (or processor consistency). > The tutorial explains precisely what this means to you > as a programmer. I've been reading the SPARC Arch manual for a long time, especially the sections on 'memory models'. I just had no idea that intel implemented these type of optimizations and thought that it always followed the strong memory model (TSO). oops? :) Thank you for the reference I'll be sure to read it throughly before touching any of the asm or consider myself viable as a reviewer for such changes. thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 23 12:53:34 1999 Delivered-To: freebsd-smp@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 91F0115396 for ; Tue, 23 Nov 1999 12:53:28 -0800 (PST) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id OAA06736; Tue, 23 Nov 1999 14:52:51 -0600 (CST) Date: Tue, 23 Nov 1999 14:52:51 -0600 From: Alan Cox To: Alfred Perlstein Cc: Matthew Dillon , Poul-Henning Kamp , Peter Wemm , Tommy Hallgren , freebsd-smp@freebsd.org Subject: Re: Matt's new unlock optimiazation Message-ID: <19991123145251.N27120@cs.rice.edu> References: <19991123142253.M27120@cs.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: ; from Alfred Perlstein on Tue, Nov 23, 1999 at 01:09:44PM -0800 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Careful... TSO is actually a "weaker" memory ordering. The tutorial compares TSO and PC on page 15. PC is pretty straightforward. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 25 7:54:15 1999 Delivered-To: freebsd-smp@freebsd.org Received: from chuldo.krc.ac.kr (chuldo.krc.ac.kr [210.119.44.12]) by hub.freebsd.org (Postfix) with SMTP id A40C714CBF for ; Thu, 25 Nov 1999 07:54:09 -0800 (PST) (envelope-from korea@mail.net) Received: from mg (U210-181-76-120.thrunet.com [210.181.76.120]) by chuldo.krc.ac.kr (8.6.12h2/8.6.9) with SMTP id AAA10445 for ; Fri, 26 Nov 1999 00:38:25 +0900 Message-Id: <199911251538.AAA10445@chuldo.krc.ac.kr> From: =?EUC-KR?B?sei/tcDP?= To: freebsd-smp@freebsd.org Subject: =?EUC-KR?B?sbmzu8PWw8o=?=! =?EUC-KR?B?u+e+98Gkurg=?=CD=?EUC-KR?B?uKY=?= =?EUC-KR?B?sPiws8fVtM+02Q==?=! Date: Sun, 07 Nov 99 00:54:09 =?EUC-KR?B?tOvH0bnOsbk=?= =?EUC-KR?B?x6XB2L3D?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=AD_2000_PART_BOUNDARY_19990606 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --AD_2000_PART_BOUNDARY_19990606 Content-Type: text/plain Content-Transfer-Encoding: 7Bit $)C !^>H3gGO<F7!@G 3;?k@; CD 1@e?! x@88.6s :>4O4Y. !^w?! A61W86GQ 55?r@L 5G8.6s4B A&@[Ax@G 9Y6x@T4O4Y. !^88>` 18@THD 3;?k@L :N=GGO4Y0m FG4\5G=C8i 100%H/:R! HDn55 @|Gt x4B A$:8CD! 23b0#@G A$<:@L 4c1d A$:8CD8& Fr0!GO?)AV=C1b 9Y6x4O4Y. !^Av1] ?,6tGO=C8i 5K4O4Y."O011-520-3877@SH/5? 8^@O@L :RGJ?dGQ:P224B 9L>HGU4O4Y.?,6tAV=C8i ;hA&GO0Z=@4O4Y."Qkoreanmask@hanmail.net &.&,&,&,&,&,&,&,&,&,&,&,&,&,&,&,&/ &-"M 9dAY1CD!G ?5H-@=>G @O9]@=>G D37Q<[ H?0z@=Gb 4. :qAn4O=: 8p@=A}(72.6MB) 0fA&@|8A 8p@= :%C31b>w @Z7a w 8p@= ;g>w 8p@= ?)<:C">w 8p@= ?@F[C">w 8p@= @N8FH0?k @Z7a @O9]1$0m @Z7a @O:;;g>w A$:8 @e;g0|7C 8p@= AV=D0|7C 8p@= C">w0-AB 8p@= C">w@|7+ 8p@= C<@N8pA} @Z7a 5. ;}H0@/8S 8p@=A}(4.92MB) ;u?l1x =C8.An <==:0|7C @/8S =d77GQ @/8S >FBw 1t:} =C8.An >vC;3- @/8S8p@= @O9] @/8S8p@= CV=E @/8S8p@= PCEk=E @/8S 6. ?5>nGP=@ @Z7a=G(18.2MB) 3W?@9.9} 9_@= ?5H-4k:; CJ1^?5>n DZ8.>FE8@SAn Grammer Hearing Native Reading Speaking Util Word Writing ?5>nK6c;l82 >K>F<- AA@:0M5i ?,>VGP 0-AB ?d8.0-AB @NEM3]0|7C @bGP;s=D @gEWE) H-GU<-=D 8p@=A}(52.3MB) 0f8.?! 0|GQ <-=D 0|8.?! 0|GQ <-=D 1bH9?! 0|GQ <-=D 4kGP?! 0|GQ <-=D :q<-?! 0|GQ <-=D ?5>w?! 0|GQ <-=D @N;g?! 0|GQ <-=D @O9] <-=D 8p@=A} @|:N<- 0x5? <-=D C$1G?! 0|GQ <-=D CQ9+?! 0|GQ <-=D H80h?! 0|GQ <-=D 11. CT?5;gAx 8p@=A}(16.9MB) 5?90;gAx 8p@= 9h0f;gAx 8p@= =D90;gAx 8p@= UFO ;gAx 8p@= 12. DD=:EM5p @Z7a=G(10.2MB) 1W7!GH 0|7C 3*8p 8^4:>s 3WF.?w 0|7C 3kF.:O 0|7C =C=:E[ ?!7/0|7C =G@| 79DZ5y >PC` 0|7C ?v5e 0|7C @)55?l 0|7C @/4P=: & 8.4*=: @NEM3] 0|7C D,EW@O97 <38m<- GO5e?~>n 0|7C Bios 0|7C Dos 0|7C 9+7a0hA$(420319-51503) s @NEM3] ?*;g 9W 03?d DDG;EM @_GO4B 9f9} DDG;EM 0|7C @Z0]Au DDG;EM ;!8. 9h?l1b ?\... 13. GXE70|7C @Z7a=G(22.1MB) ;* ?@8.GG=: GXE7 GP=@ Blue Cmaster4 Crack Cvir Gw hacker Jack Jaup Map Nevuniv Revela Soft95 Softice Sr609 Virus CV1YGXE7@G @/G| FD@L>n?y hack 14. H(Fd@LAv F@LD\ ?rAw@L4B D?<- @b5?;g4O DD0|7C G%AvFG H-;lG% Win98 !X@'@G 8p5g3;?k@L CD1@e?! n@V4B <<0hCVCJ@G A$:8CD@T4O4Y. 9dAY@: 193;CVCJ7N 885i>nAx @NEM3]A>GUA$:8 9i0z;g@|@87N @NEM3] A$:8@G  0x@/?M 4kA_H-8& @'GX 885i>nA3=@4O4Y......... !XCD18@T 9W 9.@G:011-520-3877 @SH/5?  CD18@T@: A6Ho@:G`(801-04-928554:@SH/5?)@87N @T1](33,000?x/EC9h?l<[7a FwGT)GO=C8i 5n1b/EC9h7N 9_<[GU4O4Y. !X88>` CD@G 3;?k@L :N=GGO4Y8i 100%H/:R GU4O4Y. 23b0# AX:qGQ >vC;3- @Z7a8& CD1@e?! 4c>R=@4O4Y.Fr0!9Y6x4O4Y! !X4k:P7y16GW8q/A_:P7y358Fz4u/; Sat, 27 Nov 1999 19:53:29 -0800 (PST) (envelope-from seanj@speakeasy.org) Received: from localhost (seanj@localhost) by grace.speakeasy.org (8.9.1/8.9.1) with ESMTP id TAA10874 for ; Sat, 27 Nov 1999 19:53:28 -0800 Date: Sat, 27 Nov 1999 19:53:28 -0800 (PST) From: Sean Jensen-Grey To: freebsd-smp@freebsd.org Subject: update for known hardware 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 I am sure others on the list have brought this up but the web page doesn't list the Abit BP6 motherboard as SMP aware under FBSD. I am using 3.2 and 3.3 with a dual celeron board under freebsd. link http://www.abit.com.tw Sean. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message