From owner-freebsd-smp@FreeBSD.ORG Wed Dec 14 05:55:35 2005 Return-Path: X-Original-To: freebsd-smp@freebsd.org 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 726B516A41F for ; Wed, 14 Dec 2005 05:55:35 +0000 (GMT) (envelope-from bozden@ttnet.net.tr) Received: from fep04.ttnet.net.tr (mail.ttnet.net.tr [212.175.13.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AAFB43D5E for ; Wed, 14 Dec 2005 05:55:33 +0000 (GMT) (envelope-from bozden@ttnet.net.tr) Received: from ttnet.net.tr ([85.102.188.68]) by fep04.ttnet.net.tr with ESMTP id <20051214055258.EUVV1378.fep04.ttnet.net.tr@ttnet.net.tr> for ; Wed, 14 Dec 2005 07:52:58 +0200 Message-ID: <126750-220051231455523951@ttnet.net.tr> From: bozden@ttnet.net.tr To: "q" Date: Wed, 14 Dec 2005 07:55:23 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-NAI-Spam-Rules: 0 Rules triggered Subject: q X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2005 05:55:35 -0000 q From owner-freebsd-smp@FreeBSD.ORG Thu Dec 15 00:52:58 2005 Return-Path: X-Original-To: freebsd-smp@FreeBSD.org 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 8B47B16A41F for ; Thu, 15 Dec 2005 00:52:58 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: from web32910.mail.mud.yahoo.com (web32910.mail.mud.yahoo.com [68.142.206.57]) by mx1.FreeBSD.org (Postfix) with SMTP id CD1B143D5F for ; Thu, 15 Dec 2005 00:52:56 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: (qmail 90595 invoked by uid 60001); 15 Dec 2005 00:52:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=MpNDRU/G8VWX8ly/qcbViruppkcN1v2xie1cCNuDuHSUKgV5aMIuvq9JWiHgzTDM+v5P6JImAmIhlbB31YF4XOktDkF6HUF1eMBtYZkZo/aCRwWxoFAnaX6VXb1wPFsncK6VgftvPlzRaBvBW6uquK1ItwYPiMSWjzX05RUWZbs= ; Message-ID: <20051215005253.90593.qmail@web32910.mail.mud.yahoo.com> Received: from [69.79.49.241] by web32910.mail.mud.yahoo.com via HTTP; Thu, 15 Dec 2005 01:52:53 CET Date: Thu, 15 Dec 2005 01:52:53 +0100 (CET) From: To: freebsd-smp@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1875661510-1134607973=:90525" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Pentium-D and SMP X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfgshield-freebsd@yahoo.com List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2005 00:52:58 -0000 --0-1875661510-1134607973=:90525 Content-Type: text/plain; charset=iso-8859-1 Content-Id: Content-Disposition: inline Hi; I installed FreeBSD-AMD64 on my New Dell Dimension 9150. This processor in particular (820) has two cores but no hyperthreading: http://indigo.intel.com/compare_cpu/default.aspx?familyID=1&culture=en-US The dmesg (attached) is somewhat confusing though: - It looks like hyperthreading is *detected* ??? - CPU #1 is "launched", so I guess CPU #0 was already running right? - The coredumps at the end were caused by atlas-devel trying to find out the processor I am using, looks like it only found one so it defaulted to no threads.. I think it builds another (threaded) version afterwards so I'm not sure what is really happening. It's really cool to see both amd64 and smp working together... thanks for the good work! cheers, Pedro. ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.messenger.yahoo.com --0-1875661510-1134607973=:90525-- From owner-freebsd-smp@FreeBSD.ORG Thu Dec 15 16:12:33 2005 Return-Path: X-Original-To: freebsd-smp@freebsd.org 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 92A2616A438 for ; Thu, 15 Dec 2005 16:12:33 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6722643D6D for ; Thu, 15 Dec 2005 16:12:21 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3869004 for multiple; Thu, 15 Dec 2005 11:10:20 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBFGCF6l069925; Thu, 15 Dec 2005 11:12:15 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-smp@freebsd.org, pfgshield-freebsd@yahoo.com Date: Thu, 15 Dec 2005 11:12:44 -0500 User-Agent: KMail/1.8.2 References: <20051215005253.90593.qmail@web32910.mail.mud.yahoo.com> In-Reply-To: <20051215005253.90593.qmail@web32910.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512151112.45625.jhb@freebsd.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Subject: Re: Pentium-D and SMP X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2005 16:12:33 -0000 On Wednesday 14 December 2005 07:52 pm, pfgshield-freebsd@yahoo.com wrote: > Hi; > > I installed FreeBSD-AMD64 on my New Dell Dimension 9150. This processor in > particular (820) has two cores but no hyperthreading: > > http://indigo.intel.com/compare_cpu/default.aspx?familyID=1&culture=en-US > > The dmesg (attached) is somewhat confusing though: > - It looks like hyperthreading is *detected* ??? You mean it has the HTT bit set in features? The bit just means you can ask it how many threads it has. CPUs without HTT but with the HTT cpuid feature just say they have 1 core. > - CPU #1 is "launched", so I guess CPU #0 was already running right? Yes. > - The coredumps at the end were caused by atlas-devel trying to find out > the processor I am using, looks like it only found one so it defaulted to > no threads.. I think it builds another (threaded) version afterwards so I'm > not sure what is really happening. ?? Missing attachment maybe? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-smp@FreeBSD.ORG Thu Dec 15 16:17:45 2005 Return-Path: X-Original-To: freebsd-smp@freebsd.org 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 06D9716A41F for ; Thu, 15 Dec 2005 16:17:45 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2093F43D5E for ; Thu, 15 Dec 2005 16:17:44 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by zproxy.gmail.com with SMTP id z6so437977nzd for ; Thu, 15 Dec 2005 08:17:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S2aM5hmNQvr0hvcJXQMb6KBmeFDGLDwUWaG9xbJUjZ4EvjXlBTVbmoM6zrZV4mfaNeQosxVZ/gDL/zC32Jk4cIzDG7xJx8x07dzI6TmH0G5zZzm7k3CI8zUkK2a0XMCXjuRcEhrL27KTpRScY65fll8rGKjk+Gnc2cXbiIcH7Sw= Received: by 10.37.22.8 with SMTP id z8mr2121991nzi; Thu, 15 Dec 2005 08:17:42 -0800 (PST) Received: by 10.36.43.18 with HTTP; Thu, 15 Dec 2005 08:17:42 -0800 (PST) Message-ID: <3bbf2fe10512150817s346d621do@mail.gmail.com> Date: Thu, 15 Dec 2005 08:17:42 -0800 From: rookie To: John Baldwin In-Reply-To: <200512151017.12168.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1fa17f810512150652h5da6a6a5g3347f841a614689e@mail.gmail.com> <200512151017.12168.jhb@freebsd.org> Cc: freebsd-smp@freebsd.org Subject: Re: Use turnstile to implement sx_lock X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rookie@gufi.org List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2005 16:17:45 -0000 2005/12/15, John Baldwin : > > You have to add a second queue to the turnstile and make priority > propagation > still work, etc. Mutexes would just use the exclusive queue all the time > whereas rwlocks would use both queues. This is the hard part of the rwlo= ck > project. I've sort-of started on this but haven't gotten very far at all= in > my jhb_lock p4 branch. I'm working on the same problem too and I found another solution beacause, in order to mantain a clean design, maybe modifying turnstiles code is not the better idea. If we have a thread trying to slock it just blocks if sx is held in "exclusive mode" by another thread so it's enough a simple turnstile as for other blocking locks and we have nice priorty propagation. The real problem is when we try to xlock. A xlocking thread blocks if sx is held in "shared mode" (even by different owners) so we might mantain a track of every slocking thread (through a tailqueue, a static array or whatever) in order to have a priority propagation for those. I think (I didn't implement yet) it can be done outside the turnstile context so it seems we don't necessary need to modify. Finally, we might consider one thing: turnstile has just one owner while we have (in the slocks) more than one and so what's the real owner? We could use a "head thread" per track which must be treacted carefully (EG: on slocking it we might switch the turnstile owner). What do you think about? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-smp@FreeBSD.ORG Thu Dec 15 17:13:29 2005 Return-Path: X-Original-To: freebsd-smp@freebsd.org 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 AAE8116A41F for ; Thu, 15 Dec 2005 17:13:29 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: from web32906.mail.mud.yahoo.com (web32906.mail.mud.yahoo.com [68.142.206.53]) by mx1.FreeBSD.org (Postfix) with SMTP id ACDEE43D45 for ; Thu, 15 Dec 2005 17:13:28 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: (qmail 36885 invoked by uid 60001); 15 Dec 2005 17:13:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=wu3S2f4h450JjaHkGlAa2cR3xG449VDwwhAz1L9dNt2DUekvPh3aReKoIbYXoUnm5E99VDmOX/wq+kwu2J/uimO66QmFM8AcP78z2Yx9XD7xyLOr5dZ+8LRNqyrZhM/BOUgIRtcuI0JTCRYEG82RXnLqVYJVGdZ9R0ZJyGTJ7Vg= ; Message-ID: <20051215171328.36883.qmail@web32906.mail.mud.yahoo.com> Received: from [69.79.49.241] by web32906.mail.mud.yahoo.com via HTTP; Thu, 15 Dec 2005 18:13:28 CET Date: Thu, 15 Dec 2005 18:13:28 +0100 (CET) From: To: John Baldwin , freebsd-smp@freebsd.org In-Reply-To: <200512151112.45625.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Cc: Subject: Re: Pentium-D and SMP X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfgshield-freebsd@yahoo.com List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2005 17:13:29 -0000 --- John Baldwin ha scritto: > > You mean it has the HTT bit set in features? The bit just means you can ask > it how many threads it has. CPUs without HTT but with the HTT cpuid feature > just say they have 1 core. > OK .. everything is fine then.. I guess. Since the mailer dropped the attachment I'll paste the dmesg FYI. (FWIW, A NIC, a winmodem and the audigy sound don't work yet). cheers, Pedro. ___________________ Copyright (c) 1992-2005 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 6.0-RELEASE #1: Wed Dec 14 19:10:30 COT 2005 root@etoile.cable.net.co:/usr/src/sys/amd64/compile/DIMENSION ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2793.09-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf44 Stepping = 4 Features=0xbfebfbff Features2=0x641d> AMD Features=0x20100800 Hyperthreading: 2 logical CPUs real memory = 535347200 (510 MB) avail memory = 506810368 (483 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 10 on acpi0 pci_link2: irq 4 on acpi0 pci_link3: on acpi0 pci_link4: irq 10 on acpi0 pci_link5: irq 9 on acpi0 pci_link6: irq 5 on acpi0 pci_link7: irq 3 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci1: at device 0.1 (no driver attached) pci0: at device 27.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.4 on pci0 pci3: on pcib3 pcib4: irq 17 at device 28.5 on pci0 pci4: on pcib4 pci4: at device 0.0 (no driver attached) uhci0: port 0xff80-0xff9f irq 21 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xff60-0xff7f irq 22 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xff20-0xff3f irq 23 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xffa80800-0xffa80bff irq 21 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: waiting for BIOS to give up control usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib5: at device 30.0 on pci0 pci5: on pcib5 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xbcc0-0xbcff irq 16 at device 4.0 on pci5 miibus0: on xl0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:60:08:9b:fe:c8 pci5: at device 5.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf irq 16 at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfea0-0xfeaf mem 0xefffbc00-0xefffbfff irq 20 at device 31.2 on pci0 ata2: on atapci1 ata3: on atapci1 ata4: on atapci1 ata5: on atapci1 pci0: at device 31.3 (no driver attached) orm0: at iomem 0xc0000-0xccfff,0xcd000-0xcefff,0xcf000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 device_attach: atkbd0 attach returned 6 ppc0: cannot reserve I/O port range sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ukbd0: Dell Dell USB Keyboard, rev 1.10/2.00, addr 2, iclass 3/1 kbd0 at ukbd0 ums0: Dell Dell USB Mouse, rev 1.10/29.10, addr 3, iclass 3/1 ums0: 3 buttons and Z dir. Timecounters tick every 1.000 msec acd0: DVDROM at ata0-master UDMA33 acd1: DVDR at ata0-slave UDMA33 ad4: 152587MB at ata2-master SATA150 lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s4a xl0: link state changed to UP ____________ ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.messenger.yahoo.com From owner-freebsd-smp@FreeBSD.ORG Thu Dec 15 17:57:15 2005 Return-Path: X-Original-To: freebsd-smp@freebsd.org 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 685B016A41F for ; Thu, 15 Dec 2005 17:57:15 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B52E43D46 for ; Thu, 15 Dec 2005 17:57:14 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3874577 for multiple; Thu, 15 Dec 2005 12:55:11 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBFHuqG8070481; Thu, 15 Dec 2005 12:57:04 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: pfgshield-freebsd@yahoo.com Date: Thu, 15 Dec 2005 12:48:34 -0500 User-Agent: KMail/1.8.2 References: <20051215171328.36883.qmail@web32906.mail.mud.yahoo.com> In-Reply-To: <20051215171328.36883.qmail@web32906.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512151248.34805.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=ALL_TRUSTED, UPPERCASE_25_50 autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-smp@freebsd.org Subject: Re: Pentium-D and SMP X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2005 17:57:15 -0000 On Thursday 15 December 2005 12:13 pm, pfgshield-freebsd@yahoo.com wrote: > --- John Baldwin ha scritto: > > You mean it has the HTT bit set in features? The bit just means you can > > ask it how many threads it has. CPUs without HTT but with the HTT cpuid > > feature just say they have 1 core. > > OK .. everything is fine then.. I guess. > > Since the mailer dropped the attachment I'll paste the dmesg FYI. (FWIW, A > NIC, a winmodem and the audigy sound don't work yet). > > Features=0xbfebfbffA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0x641d> > AMD Features=0x20100800 > Hyperthreading: 2 logical CPUs I think 6.1 and 7.0 will fix this to say that these are cores rather than logical CPUs btw. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-smp@FreeBSD.ORG Thu Dec 15 17:57:25 2005 Return-Path: X-Original-To: freebsd-smp@freebsd.org 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 114D116A41F for ; Thu, 15 Dec 2005 17:57:25 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44F4D43D66 for ; Thu, 15 Dec 2005 17:57:23 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3874580 for multiple; Thu, 15 Dec 2005 12:55:13 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBFHuqG9070481; Thu, 15 Dec 2005 12:57:09 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: rookie@gufi.org Date: Thu, 15 Dec 2005 12:57:21 -0500 User-Agent: KMail/1.8.2 References: <1fa17f810512150652h5da6a6a5g3347f841a614689e@mail.gmail.com> <200512151017.12168.jhb@freebsd.org> <3bbf2fe10512150817s346d621do@mail.gmail.com> In-Reply-To: <3bbf2fe10512150817s346d621do@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512151257.22004.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-smp@freebsd.org Subject: Re: Use turnstile to implement sx_lock X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2005 17:57:25 -0000 On Thursday 15 December 2005 11:17 am, rookie wrote: > 2005/12/15, John Baldwin : > > You have to add a second queue to the turnstile and make priority > > propagation > > still work, etc. Mutexes would just use the exclusive queue all the time > > whereas rwlocks would use both queues. This is the hard part of the > > rwlock project. I've sort-of started on this but haven't gotten very far > > at all in my jhb_lock p4 branch. > > I'm working on the same problem too and I found another solution > beacause, in order to mantain a clean design, maybe modifying > turnstiles code is not the better idea. > If we have a thread trying to slock it just blocks if sx is held in > "exclusive mode" by another thread so it's enough a simple turnstile > as for other blocking locks and we have nice priorty propagation. The > real problem is when we try to xlock. A xlocking thread blocks if sx > is held in "shared mode" (even by different owners) so we might > mantain a track of every slocking thread (through a tailqueue, a > static array or whatever) in order to have a priority propagation for > those. I think (I didn't implement yet) it can be done outside the > turnstile context so it seems we don't necessary need to modify. > Finally, we might consider one thing: turnstile has just one owner > while we have (in the slocks) more than one and so what's the real > owner? > We could use a "head thread" per track which must be treacted > carefully (EG: on slocking it we might switch the turnstile owner). > > What do you think about? As per the description, I suggest go reading up on rwlocks in Solaris Internals. The method they use is turnstiles with 2 queues, and for an rwlock that is read locked, they have the concept of the 'owner of record' which is basically the first thread to acquire a read lock, and you just bump their priority and no one else's. When they drop the read lock, if someone else has it, you just have no one to propagate the priority to. BTW, I don't think sx locks should use turnstiles, but a new rwlock primitive that has a similar API. The reason is that sx locks can be held across sleep right now (and are often used that way), but a rwlock that uses turnstiles won't be sleepable, just as mutexes aren't sleepable. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-smp@FreeBSD.ORG Thu Dec 15 20:25:18 2005 Return-Path: X-Original-To: freebsd-smp@freebsd.org 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 D134316A422; Thu, 15 Dec 2005 20:25:18 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2641D43D5E; Thu, 15 Dec 2005 20:25:17 +0000 (GMT) (envelope-from max@love2party.net) Received: from [84.163.255.59] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML2ov-1EmzfA1VDY-0002BL; Thu, 15 Dec 2005 21:25:16 +0100 From: Max Laier Organization: FreeBSD To: rookie@gufi.org Date: Thu, 15 Dec 2005 21:25:09 +0100 User-Agent: KMail/1.8.2 References: <1fa17f810512150652h5da6a6a5g3347f841a614689e@mail.gmail.com> <200512151257.22004.jhb@freebsd.org> <3bbf2fe10512151109w22ef9e2aj@mail.gmail.com> In-Reply-To: <3bbf2fe10512151109w22ef9e2aj@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7416933.bpJBzqqVCP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512152125.16004.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-smp@freebsd.org Subject: Re: Fwd: Use turnstile to implement sx_lock X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2005 20:25:19 -0000 --nextPart7416933.bpJBzqqVCP Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 15 December 2005 20:09, rookie wrote: > Maybe you're not subscribed to smp@ Indeed I'm not - fixed. > What do you think about? See below. > ---------- Forwarded message ---------- > From: John Baldwin > Date: 15-dic-2005 18.57 > Subject: Re: Use turnstile to implement sx_lock > To: rookie@gufi.org > Cc: freebsd-smp@freebsd.org > > On Thursday 15 December 2005 11:17 am, rookie wrote: > > I'm working on the same problem too and I found another solution > > beacause, in order to mantain a clean design, maybe modifying > > turnstiles code is not the better idea. > > If we have a thread trying to slock it just blocks if sx is held in > > "exclusive mode" by another thread so it's enough a simple turnstile > > as for other blocking locks and we have nice priorty propagation. The After some thinking this strikes me as wrong. You must not grant a slock=20 attempt if there is a thread with a higher priority waiting to get a xlock.= =20 This does not mean that your approach doesn't work, but you have to keep th= is=20 in mind. > > real problem is when we try to xlock. A xlocking thread blocks if sx > > is held in "shared mode" (even by different owners) so we might > > mantain a track of every slocking thread (through a tailqueue, a > > static array or whatever) in order to have a priority propagation for > > those. I think (I didn't implement yet) it can be done outside the > > turnstile context so it seems we don't necessary need to modify. > > Finally, we might consider one thing: turnstile has just one owner > > while we have (in the slocks) more than one and so what's the real > > owner? > > We could use a "head thread" per track which must be treacted > > carefully (EG: on slocking it we might switch the turnstile owner). > > > > What do you think about? > > As per the description, I suggest go reading up on rwlocks in Solaris > Internals. The method they use is turnstiles with 2 queues, and for an > rwlock that is read locked, they have the concept of the 'owner of record' > which is basically the first thread to acquire a read lock, and you just > bump their priority and no one else's. When they drop the read lock, if= =20 > someone else has it, you just have no one to propagate the priority to. = =20 It seems to me that you are talking about the same things with slightly=20 different implementation details. It doesn't really matter much where the= =20 queue of slocking threads is kept as long as it is easily and efficient to= =20 update the turnstile's owner on sunlock. In practice it should be easier t= o=20 have it in the turnstile as well and I still don't really understand why yo= u=20 (rookie) do not want to change turnstiles. > BTW, I don't think sx locks should use turnstiles, but a new rwlock=20 > primitive that has a similar API. The reason is that sx locks can be hel= d=20 > across sleep right now (and are often used that way), but a rwlock that u= ses=20 > turnstiles won't be sleepable, just as mutexes aren't sleepable. Agreed. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart7416933.bpJBzqqVCP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDodErXyyEoT62BG0RAqC2AJ9L6+yqLzTElEu7g/xEJpuVN+hF4wCfR+2y ZOnolCzgRX8Bp4Bkf3h3Trw= =Id6x -----END PGP SIGNATURE----- --nextPart7416933.bpJBzqqVCP-- From owner-freebsd-smp@FreeBSD.ORG Fri Dec 16 08:43:44 2005 Return-Path: X-Original-To: freebsd-smp@freebsd.org 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 26D9B16A41F for ; Fri, 16 Dec 2005 08:43:44 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id A999643D5C for ; Fri, 16 Dec 2005 08:43:43 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by zproxy.gmail.com with SMTP id z6so621985nzd for ; Fri, 16 Dec 2005 00:43:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VFD7xPmxv7fQSt1R13cxJLvHC60ALpVXOqOO6nbu9teqfOQvjcG7jMKmmWZCv3e4KRvQvVnI750BD2viDmdEyQEouUfIFw1MmACUj4apWmEWz27MdZmRjSuYNVRbng/rC+UWpCt6SYnIf3YmZiFtJAXaIxNR1CbzfO1oedmLuDE= Received: by 10.36.32.14 with SMTP id f14mr2335505nzf; Fri, 16 Dec 2005 00:43:40 -0800 (PST) Received: by 10.36.43.18 with HTTP; Fri, 16 Dec 2005 00:43:39 -0800 (PST) Message-ID: <3bbf2fe10512160043g2777a8f9t@mail.gmail.com> Date: Fri, 16 Dec 2005 00:43:39 -0800 From: rookie To: freebsd-smp@freebsd.org In-Reply-To: <3bbf2fe10512160041x7fd719bej@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1fa17f810512150652h5da6a6a5g3347f841a614689e@mail.gmail.com> <200512151257.22004.jhb@freebsd.org> <3bbf2fe10512151109w22ef9e2aj@mail.gmail.com> <200512152125.16004.max@love2party.net> <3bbf2fe10512160041x7fd719bej@mail.gmail.com> Subject: Re: Use turnstile to implement sx_lock X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rookie@gufi.org List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2005 08:43:44 -0000 > After some thinking this strikes me as wrong. You must not grant a slock > attempt if there is a thread with a higher priority waiting to get a xloc= k. > This does not mean that your approach doesn't work, but you have to keep > this > in mind. Yes, it's right. [snip] > > It seems to me that you are talking about the same things with slightly > different implementation details. It doesn't really matter much where th= e > queue of slocking threads is kept as long as it is easily and efficient t= o > update the turnstile's owner on sunlock. In practice it should be easier= to > have it in the turnstile as well and I still don't really understand why = you > (rookie) do not want to change turnstiles. In order to mantain current code for mutex (less changes mean less problems= ). However I think that a good start point would be writing code for a new primitive (as John and Max suggested) and I will concentrate my work there. Attilio -- Peace can only be achieved by understanding - A. Einstein