From owner-freebsd-smp Sun Jun 20 5:34:57 1999 Delivered-To: freebsd-smp@freebsd.org Received: from ipamzlx.physik.uni-mainz.de (ipamzlx.Physik.Uni-Mainz.DE [134.93.180.54]) by hub.freebsd.org (Postfix) with ESMTP id 4B21214D54 for ; Sun, 20 Jun 1999 05:34:48 -0700 (PDT) (envelope-from ohartman@ipamzlx.physik.uni-mainz.de) Received: from ipamzlx.Physik.Uni-Mainz.DE (ipamzlx.Physik.Uni-Mainz.DE [134.93.180.54]) by ipamzlx.physik.uni-mainz.de (8.9.3/8.9.3) with ESMTP id OAA55679 for ; Sun, 20 Jun 1999 14:34:47 +0200 (CEST) (envelope-from ohartman@ipamzlx.physik.uni-mainz.de) Date: Sun, 20 Jun 1999 14:34:47 +0200 (CEST) From: "O. Hartmann" To: freebsd-smp@freebsd.org Subject: SMP, 4GB RAM, 4x CPU 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 Dear Sirs. It is really hard to figure out how "good" the SMP implementation of FreeBSD is. I have had a lot of discussions with other FBSD users, developers, scientists using FBSD boxes and I got a summary of information which is confusing me. The situation in our lab is this: I built up a server for our NT Workstations to serve lots of drivespaces, building up a database and a webserver for our meteorological datas. Some guys from our theoretical meteorological group now want to use the SMP sytem (2x 350MHz Intel PII, 256 MB RAM). They use lots of fortran programs. The first tests offered that FreeBSD is not dispatching fortran jobs so jobs are running either on CPU0 or on CPU1. Well, it doesn't matter, we can start up two similar jobs to get the result in the time as we have used only the 350MHz system with UP ( :-( ). Now the discussion is going on to buy a new system for the whole institute (we are operating as small workgroups with a limited budget ...). For such enormous numbercrunching purposes we considered to buy (money rules, sorry, no Alpha!) a 4x SMP machine with 2 or 4GB RAM to server the necessary performance and to keep costs low -> so we have to rely on a free UN*X and I like FBSD because of its stability ... and I like BSD style systems. But that is not the question. We heard about tests, tests and tests again, made with the new Linux kernel (2.2x) and many provider offering so called "number crunching" Linux systems with 2 CPUs ( P III/550MHz). I read a lot about problems with DRAM growing up to 4GB and problems with 4 CPUs. I have problems with two - how big are then problems and "performance losses" with four CPUs ... Again, and again, I see so many unreflecting "performance tests" made by simply compiling the system. No, no, no. Well, listen to this: some guy wrote me, that he use an AMD K6-2/400MHz with 128MB SDRAM/100. It's system is ready within 45 minutes. That seems really fast! I have two 350MHz CPUs, 256 MBytes of RAM (upgrading to 512 MBytes next time) and my /usr/obj and /usr/src tree are on two different SCSI devices (UW, Adaptec 2940). When I tested the "make buildworld speed" of our "fast" system I always get a maketime of 90 to 100 minutes. That's funny, isn't it? Well, I tried make -j8, make -j12, make -j16 and lowered it to make -j5, but always the same result - and be aware of the fact, that the system is not used in the time of making world!!!! My question is, hopefuly, simple: I need objective and true informations about how "ggod" the SMP implementation of FreeBSD 3.2 is, how "stable" and usable the system is for usage with 4x CPU (Xeon) and 4GB RAM. We have some offers of Fortran vendors, and I don't want me spending a lot of money for a Linux- emulation to get not the power of the native system running on a Linux box. Where is the FreeBSD-SMP Roadmap? What has changed in FBSD 4.0? I don't want to start a polemic or philosophic discissuion, I need serious facts ... Thank you a lot in advance and thanks for all the guys who have written to me in the past. O. Hartmann Gruss O. Hartmann ------------------------------------------------------------------- ohartman@ipamzlx.physik.uni-mainz.de Klimadatenserver des IPA, Universitaet Mainz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jun 20 11:46:31 1999 Delivered-To: freebsd-smp@freebsd.org Received: from cannon.ma.ikos.com (cannon.ma.ikos.com [137.103.105.19]) by hub.freebsd.org (Postfix) with ESMTP id A722214C17 for ; Sun, 20 Jun 1999 11:46:20 -0700 (PDT) (envelope-from tich@cannon.ma.ikos.com) Received: from isolation.ma.ikos.com (isolation [137.103.105.11]) by cannon.ma.ikos.com (8.9.1/8.8.8) with ESMTP id OAA08059; Sun, 20 Jun 1999 14:42:48 -0400 (EDT) From: Richard Cownie Received: (from tich@localhost) by isolation.ma.ikos.com (8.8.8/8.8.8) id OAA18071; Sun, 20 Jun 1999 14:40:25 -0400 (EDT) Date: Sun, 20 Jun 1999 14:40:25 -0400 (EDT) Message-Id: <199906201840.OAA18071@isolation.ma.ikos.com> To: freebsd-smp@FreeBSD.ORG, ohartman@ipamzlx.physik.uni-mainz.de Subject: Re: SMP, 4GB RAM, 4x CPU Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Since I'm the source of recent messages about problems with 4 cpu's and 4GB dram, I'll respond. 1) To the best of my knowledge, 3.2-STABLE works fine with 4 cpu's, but does not yet support 4GB DRAM. Not sure if it works with 3GB ? 2) To get the use of 4GB dram, I am running 19990604-CURRENT. This has problems with 4GB dram (but I've submitted a fix), and also with 4 cpu's. However, in the nature of software development, if you're running -current then things will be broken from time to time. This seems to be particularly true of 4GB/4cpu stuff because very few people have these kinds of systems. If you can cope with the dram limits in 3.2-STABLE, then that's probably what you should plan to use to get real work done. 3) The Linux alternative is interesting and I have myself given this serious consideration. For my particular application, the show-stopper is that Linux will only handle 2GB of DRAM; also it's unclear how big a single process can be - I believe there are problems around 1GB. With FreeBSD I can use 4GB of DRAM (actually 3998MB for arcane chipset reasons), and a single process can get >2.5GB - with further tuning of kernel configuration I believe a single process can be >3.5GB. So if your applications need large virtual memory OR large physical memory, Linux just doesn't cut it. 4) The biggest system we have here is an Intel SC450NX from SAG Electronics (www.sagelec.com) with 4 x Xeon-500MHz, 4GB DRAM, 6 x 9GB disk. Total cost approx $21K. This machine is very very fast and I'm happy with it (running FreeBSD). 5) There are two different issues which may cause trouble with performance scaling to 4 cpus: a) Memory bandwidth. For the EDA applications we're running, cache locality even with 512K cache is pretty good, my rough estimate is that each extra cpu slows down the other's by 5%, so total throughput for 1,2,3,4 jobs is about 1.0, 1.9, 3.2, 3.4 But the machine so fast that we rarely have 4 jobs running simultaneously. b) Contention for kernel resources. I believe the locking in the FreeBSD kernel is not very fine-grained as yet, so if several cpu's are trying to make system calls all at once, they'll be largely serialized ? However, if your application spend 90% of their time in user space (and if you're doing Fortran floating-point number crunching then that's probably true), this is probably not an issue. 6) If you can get your work done with 2way SMP systems with <= 1GB dram, then these are better value than the 4way. The motherboards are cheaper, the dram is cheaper, and overclocked Celerons are an amazing bargain, e.g. see the Power2U Dude at www.computernerd.com. And of course with 2 2way systems you don't suffer the same SMP inefficiency as with 1 4way system. Good luck Richard Cownie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jun 20 23:39:42 1999 Delivered-To: freebsd-smp@freebsd.org Received: from smtp5.jps.net (smtp5.jps.net [209.63.224.55]) by hub.freebsd.org (Postfix) with ESMTP id 4D7D2152E8 for ; Sun, 20 Jun 1999 23:39:38 -0700 (PDT) (envelope-from ulairi@jps.net) Received: from ulairi (208-237-196-107.irv.jps.net [208.237.196.107]) by smtp5.jps.net (8.9.0/8.8.5) with SMTP id XAA07043 for ; Sun, 20 Jun 1999 23:39:36 -0700 (PDT) From: "Ulairi" To: "Smp" Subject: Yet another addition to the SMP motherboard hardware list Date: Sun, 20 Jun 1999 23:39:29 -0700 Message-ID: <000801bebbb0$d0300a00$6bc4edd0@ulairi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 P6DLF Bios rev 1.3 and above. General Purpose Computer Geek California State University, Northridge College of Engineering and Computer Science 18111 Nordhoff St, Post Stop 8295 Northridge, CA 91330 ulairi@jps.net ulairi@ecs.csun.edu ntadmin@ecs.csun.edu secadmin@ecs.csun.edu -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.0.2i iQA/AwUBN23dfVR8Yh25VFLEEQJt9ACdH84cAcsNvsGRjTGR3QzwF8+5QUAAoOQJ BTX01pjCVf2ado2aHbcBklO/ =Xuyj -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jun 21 2:25:27 1999 Delivered-To: freebsd-smp@freebsd.org Received: from root.azovstal.com.ua (azovstal.com.ua [195.206.225.58]) by hub.freebsd.org (Postfix) with ESMTP id 427E914DDD for ; Mon, 21 Jun 1999 02:25:04 -0700 (PDT) (envelope-from brozgol@azovstal.com.ua) Received: from brozgol (brozgol.asctp.azov.stal [10.2.1.54]) by root.azovstal.com.ua (8.9.2/8.9.2) with SMTP id MAA50518 for ; Mon, 21 Jun 1999 12:24:56 +0300 (EEST) (envelope-from brozgol@azovstal.com.ua) Message-ID: <007801bebbc8$23f40300$3601020a@brozgol.asctp.azov.stal> From: "Andrew Brozgol" To: Subject: Re: SMP panics: can't support type 2 default yet Date: Mon, 21 Jun 1999 12:26:27 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear Andrew: Thank you very much. I am so grateful for your message. It was my second message sent to that list and you were the only person to answer. You know I am not a native English speaker, so I thought the problem was in my English. > >You may be able to learn more about the "default config type" by refering >to mptable's source, and possibly by searching for MP specification >documentation on Intel's web site. If you do, and end up being able to >supply patches to add such support to the source tree, I'm sure the >patches would be welcome. > I will try to follow your advice but I am not very experienced in FreeBSD so I have to learn much. Truly, Andrew Brozgol To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jun 21 8:38:10 1999 Delivered-To: freebsd-smp@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id 8582914CFD for ; Mon, 21 Jun 1999 08:38:04 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp18388.on.bellglobal.com [206.172.130.68]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id LAA01716; Mon, 21 Jun 1999 11:40:59 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id LAA00445; Mon, 21 Jun 1999 11:38:50 -0400 (EDT) (envelope-from tim) Date: Mon, 21 Jun 1999 11:38:49 -0400 From: Tim Vanderhoek To: "O. Hartmann" Cc: freebsd-smp@freebsd.org Subject: Re: SMP, 4GB RAM, 4x CPU Message-ID: <19990621113849.A266@mad> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from O. Hartmann on Sun, Jun 20, 1999 at 02:34:47PM +0200 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jun 20, 1999 at 02:34:47PM +0200, O. Hartmann wrote: > > Again, and again, I see so many unreflecting "performance tests" made by > simply compiling the system. No, no, no. Well, listen to this: some guy The only accurate performance test is reality. > My question is, hopefuly, simple: I need objective and true informations about > how "ggod" the SMP implementation of FreeBSD 3.2 is, how "stable" and usable > the system is for usage with 4x CPU (Xeon) and 4GB RAM. We have some offers ftp.cdrom.com runs FreeBSD on a Xeon/500 with 4GB ram. They have no stability problems. Obviously, they don't run fortran programs, but you shouldn't experience stability problems. I'm not sure if ftp.cdrom.com has >1 cpu, though. You shouldn't experience problems running Linux applications on FreeBSD. Linux isn't really "emulated" in the sense that applications need to be translated before being executed, but rather we just use a different set of syscall mappings for Linux programs as well as a port that installs the necessary parts of userland Linux. If Linux programs are noticeably slower due to being emulated, then that is a bug. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jun 21 8:54:40 1999 Delivered-To: freebsd-smp@freebsd.org Received: from www1.asacomputers.com (unknown [204.153.176.244]) by hub.freebsd.org (Postfix) with ESMTP id 0E66A14C4A for ; Mon, 21 Jun 1999 08:54:38 -0700 (PDT) (envelope-from kedar@asacomputers.com) Received: from kedar.asacomputers.com (kedar.asacomputers.com [204.153.176.86]) by www1.asacomputers.com (8.8.8/8.8.8) with SMTP id JAA22071; Mon, 21 Jun 1999 09:13:37 -0700 (PDT) (envelope-from kedar@asacomputers.com) Message-Id: <2.2.32.19990621154926.01faf7e8@asacomputers.com> X-Sender: rajadnya@asacomputers.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Jun 1999 08:49:26 -0700 To: Richard Cownie From: Kedar Rajadnya Subject: Re: SMP, 4GB RAM, 4x CPU Cc: freebsd-smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >2) To get the use of 4GB dram, I am running 19990604-CURRENT. This > has problems with 4GB dram (but I've submitted a fix), and also This is just a question. Do you think it would be better to use something like an Alpha 264DP in dual-cpu format(upto 4MB cache) and 4GB RAM rather than a quad xeon, 4GB RAM and a 32-bit bus? Kedar. Take care, Kedar Rajadnya. ASA Computers, Inc. 2354 Calle Del Mundo. Santa Clara, CA 95054. TEL: (408)654-2901 ext201 CELL: (408)799-7263 TOLL FREE:(877)538-1272 FAX: (408)654-2910 ***************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jun 21 9: 2:32 1999 Delivered-To: freebsd-smp@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FAF314C4A for ; Mon, 21 Jun 1999 09:02:29 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id KAA28490; Mon, 21 Jun 1999 10:01:55 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199906211601.KAA28490@panzer.plutotech.com> Subject: Re: SMP, 4GB RAM, 4x CPU In-Reply-To: <2.2.32.19990621154926.01faf7e8@asacomputers.com> from Kedar Rajadnya at "Jun 21, 1999 08:49:26 am" To: kedar@asacomputers.com (Kedar Rajadnya) Date: Mon, 21 Jun 1999 10:01:55 -0600 (MDT) Cc: tich@ma.ikos.com (Richard Cownie), freebsd-smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kedar Rajadnya wrote... > >2) To get the use of 4GB dram, I am running 19990604-CURRENT. This > > has problems with 4GB dram (but I've submitted a fix), and also > > This is just a question. Do you think it would be better to use > something like an Alpha 264DP in dual-cpu format(upto 4MB cache) and 4GB RAM > rather than a quad xeon, 4GB RAM and a 32-bit bus? It might be, if we had SMP support on the Alpha. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jun 21 9: 9: 0 1999 Delivered-To: freebsd-smp@freebsd.org Received: from www1.asacomputers.com (unknown [204.153.176.244]) by hub.freebsd.org (Postfix) with ESMTP id 1137814C4A for ; Mon, 21 Jun 1999 09:08:58 -0700 (PDT) (envelope-from kedar@asacomputers.com) Received: from kedar.asacomputers.com (kedar.asacomputers.com [204.153.176.86]) by www1.asacomputers.com (8.8.8/8.8.8) with SMTP id JAA22207; Mon, 21 Jun 1999 09:27:58 -0700 (PDT) (envelope-from kedar@asacomputers.com) Message-Id: <2.2.32.19990621160347.01591130@asacomputers.com> X-Sender: rajadnya@asacomputers.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Jun 1999 09:03:47 -0700 To: "Kenneth D. Merry" From: Kedar Rajadnya Subject: Re: SMP, 4GB RAM, 4x CPU Cc: freebsd-smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >It might be, if we had SMP support on the Alpha. Ah! But of course. Should have done my homework. Thanks. :) Kedar. Take care, Kedar Rajadnya. ASA Computers, Inc. 2354 Calle Del Mundo. Santa Clara, CA 95054. TEL: (408)654-2901 ext201 CELL: (408)799-7263 TOLL FREE:(877)538-1272 FAX: (408)654-2910 ***************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jun 21 10: 6:27 1999 Delivered-To: freebsd-smp@freebsd.org Received: from par28.ma.ikos.com (par28.ma.ikos.com [137.103.105.228]) by hub.freebsd.org (Postfix) with ESMTP id D25C715034 for ; Mon, 21 Jun 1999 10:06:24 -0700 (PDT) (envelope-from tich@par28.ma.ikos.com) Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by par28.ma.ikos.com (8.8.7/8.8.7) id NAA18274; Mon, 21 Jun 1999 13:06:10 -0400 From: Richard Cownie To: Kedar Rajadnya Subject: Re: SMP, 4GB RAM, 4x CPU Date: Mon, 21 Jun 1999 12:37:47 -0400 X-Mailer: KMail [version 1.1.0] Content-Type: text/plain Cc: freebsd-smp@FreeBSD.ORG References: <2.2.32.19990621154926.01faf7e8@asacomputers.com> MIME-Version: 1.0 Message-Id: <99062113061000.18239@par28.ma.ikos.com> Content-Transfer-Encoding: 8bit X-KMail-Mark: Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 21 Jun 1999, Kedar Rajadnya wrote: > >2) To get the use of 4GB dram, I am running 19990604-CURRENT. This > > has problems with 4GB dram (but I've submitted a fix), and also > > This is just a question. Do you think it would be better to use > something like an Alpha 264DP in dual-cpu format(upto 4MB cache) and 4GB RAM > rather than a quad xeon, 4GB RAM and a 32-bit bus? > > Kedar. I've never used an Alpha myself. From the benchmarks I've seen I believe they are substantially faster for floating point, and they have more memory bandwidth and bigger caches. So if absolute performance on floating-point intensive stuff is what you need, Alpha is worth considering. However, if price-performance is what you need, I believe a dual-Celeron at 500MHz+ with 1GB dram for $3K is about the best you can do. As far as I know the dual-Alpha systems are still up in the $10K range. This may change next year. A couple of months from now K7 systems may also be interesting (though I think we'll have to wait a while for cheap SMP-K7 systems). Also there are rumours that Alpha performance is critically dependent on the compiler used - i.e. the DEC compiler on Tru64 Unix (is that this week's name ?) might give you 30% more performance than gcc. This is third-hand information, so may be false (or it may be true for Alpha 21164 but not 21264, which I think does more dynamic scheduling ?). Be wary of the SPECint/fp results - these may be heavily influenced by the cache size, and maybe also wacky compiler options which are rarely usable in real life. As always, the correct choice depends on your particular application and financial constraints. Richard Cownie (tich@ma.ikos.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jun 21 13: 9:22 1999 Delivered-To: freebsd-smp@freebsd.org Received: from ares.cs.Virginia.EDU (ares.cs.Virginia.EDU [128.143.136.41]) by hub.freebsd.org (Postfix) with ESMTP id 4D57914F99 for ; Mon, 21 Jun 1999 13:09:18 -0700 (PDT) (envelope-from chapin@cs.virginia.edu) Received: from cs.virginia.edu (mamba.cs.Virginia.EDU [128.143.137.15]) by ares.cs.Virginia.EDU (8.9.2/8.9.2/UVACS-1999030200) with ESMTP id QAA21524; Mon, 21 Jun 1999 16:08:35 -0400 (EDT) Message-Id: <199906212008.QAA21524@ares.cs.Virginia.EDU> Reply-To: chapin@cs.virginia.edu From: chapin@cs.virginia.edu (Steve Chapin) To: Richard Cownie Cc: Kedar Rajadnya , freebsd-smp@freebsd.org Zevon-of-the-day: Stand in the Fire Subject: Re: SMP, 4GB RAM, 4x CPU In-reply-to: Your message of Mon, 21 Jun 1999 12:37:47 EDT. <99062113061000.18239@par28.ma.ikos.com> Date: Mon, 21 Jun 1999 16:08:34 -0400 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Also there are rumours that Alpha performance is critically > dependent on the compiler used - i.e. the DEC compiler on Tru64 Unix > (is that this week's name ?) might give you 30% more performance > than gcc. This is third-hand information, so may be false (or it > may be true for Alpha 21164 but not 21264, which I think does more > dynamic scheduling ?). I can confirm this for our case. We run a mixed cluster of Alpha machines (533 MHz 21664LX) and Intel machines (mostly dual Pentium II 450MHz), and the use of the "correct" compiler (especially for some of our Fortran applications) ais critical to performance on the Alphas. This isn't too surprising, as a hard-core RISC arch like the Alpha is going to be much more sensitive to proper code optimization (or lack thereof) than will the Pentium. sc -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jun 21 13:33:12 1999 Delivered-To: freebsd-smp@freebsd.org Received: from beowulf.utmb.edu (beowulf.utmb.edu [129.109.59.83]) by hub.freebsd.org (Postfix) with ESMTP id 728E014F42 for ; Mon, 21 Jun 1999 13:32:20 -0700 (PDT) (envelope-from bdodson@beowulf.utmb.edu) Received: (from bdodson@localhost) by beowulf.utmb.edu (8.9.3/8.9.2) id PAA15925; Mon, 21 Jun 1999 15:26:23 -0500 (CDT) (envelope-from bdodson) Date: Mon, 21 Jun 1999 15:26:23 -0500 (CDT) Message-Id: <199906212026.PAA15925@beowulf.utmb.edu> From: "M. L. Dodson" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: chapin@cs.virginia.edu Cc: Richard Cownie , Kedar Rajadnya , freebsd-smp@FreeBSD.ORG Subject: Re: SMP, 4GB RAM, 4x CPU In-Reply-To: <199906212008.QAA21524@ares.cs.Virginia.EDU> References: <99062113061000.18239@par28.ma.ikos.com> <199906212008.QAA21524@ares.cs.Virginia.EDU> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org So tell us: What's the trick compiler suite on Alpha (both fortran and c, preferably)? Bud Dodson Steve Chapin writes: > > > Also there are rumours that Alpha performance is critically > > dependent on the compiler used - i.e. the DEC compiler on Tru64 Unix > > (is that this week's name ?) might give you 30% more performance > > than gcc. This is third-hand information, so may be false (or it > > may be true for Alpha 21164 but not 21264, which I think does more > > dynamic scheduling ?). > > I can confirm this for our case. We run a mixed cluster of Alpha > machines (533 MHz 21664LX) and Intel machines (mostly dual Pentium II > 450MHz), and the use of the "correct" compiler (especially for some of > our Fortran applications) ais critical to performance on the > Alphas. This isn't too surprising, as a hard-core RISC arch like the > Alpha is going to be much more sensitive to proper code optimization > (or lack thereof) than will the Pentium. > > sc > -- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > -- M. L. Dodson bdodson@scms.utmb.edu 409-772-2178 FAX: 409-772-1790 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jun 21 14: 6: 5 1999 Delivered-To: freebsd-smp@freebsd.org Received: from csvax.cs.caltech.edu (csvax.cs.caltech.edu [131.215.131.131]) by hub.freebsd.org (Postfix) with ESMTP id 4E57014C2E for ; Mon, 21 Jun 1999 14:06:01 -0700 (PDT) (envelope-from mika@varese.cs.caltech.edu) Received: from varese.cs.caltech.edu (varese.cs.caltech.edu [131.215.78.28]) by csvax.cs.caltech.edu (8.9.1/8.9.1) with ESMTP id OAA26464; Mon, 21 Jun 1999 14:05:59 -0700 (PDT) Received: from localhost.cs.caltech.edu (localhost.cs.caltech.edu [127.0.0.1]) by varese.cs.caltech.edu (8.8.7/8.7.3) with SMTP id OAA29913; Mon, 21 Jun 1999 14:05:59 -0700 (PDT) Message-Id: <199906212105.OAA29913@varese.cs.caltech.edu> X-Authentication-Warning: varese.cs.caltech.edu: localhost.cs.caltech.edu [127.0.0.1] didn't use HELO protocol To: Richard Cownie Cc: freebsd-smp@freebsd.org Subject: Re: SMP, 4GB RAM, 4x CPU In-reply-to: Your message of "Mon, 21 Jun 1999 12:37:47 EDT." <99062113061000.18239@par28.ma.ikos.com> Date: Mon, 21 Jun 1999 14:05:59 -0700 From: Mika Nystrom Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Richard Cownie writes: [..] >I've never used an Alpha myself. From the benchmarks I've seen I believe >they are substantially faster for floating point, and they have more memory >bandwidth and bigger caches. So if absolute performance on floating-point >intensive stuff is what you need, Alpha is worth considering. However, >if price-performance is what you need, I believe a dual-Celeron at 500MHz+ >with 1GB dram for $3K is about the best you can do. As far as I know >the dual-Alpha systems are still up in the $10K range. This may change >next year. A couple of months from now K7 systems may also be interesting >(though I think we'll have to wait a while for cheap SMP-K7 systems). > >Also there are rumours that Alpha performance is critically dependent >on the compiler used - i.e. the DEC compiler on Tru64 Unix (is that this >week's name ?) might give you 30% more performance than gcc. This is >third-hand information, so may be false (or it may be true for Alpha 21164 >but not 21264, which I think does more dynamic scheduling ?). Be wary >of the SPECint/fp results - these may be heavily influenced by the cache size, >and maybe also wacky compiler options which are rarely usable in real life. > [..] Hello everyone, From personal experience---we use FreeBSD/SMP, mostly on dual PPro systems with up to 1GB, as well as Mach.. err OSF.. err Digital.. err.. Compaq Tru64 on a couple of Alphas (21164 @266 MHz & @500MHz). The new DEC cc (that is, /usr/bin/cc -migrate -tune ev5, etc etc etc---DEC cc is actually two compilers in one) can give a very large performance boost on the 164/ev5 as opposed to gcc; in fact, on Fortran code (which requires either f2c or even more money spent on DEC f77), I wouldn't be surprised if the performance benefit could be 100+%. But your guess as to the 264 is probably correct. The 164 is really an in-order processor, and takes a very large (up to 300% longer runtimes) performance hit for improperly scheduled code, and it also has a very long-latency memory system that places a large premium on controlling your caching behavior. We did some benchmarking a few months ago, and I believe that the 266 MHz alpha running an in-house version of SPICE was close to the same speed as a 450 MHz Pentium III (this was at the time close to the latest-and-greatest Intel chip racing a four-year-old Alpha), and the 500 MHz machine (two years old) just blew away the P-III. (Of course, DEC cc -migrate vs gcc; I believe the P-III was running Red Hat, but that shouldn't matter much.) All that being said, if you want large memory, I think a 264-based system could be better price/performance than a Xeon-based system (have you seen what the large-cache Xeons cost? sheesh!) But if you're on a tight budget, Celeron, obviously :) (And K7 soon, I hope.) Regards, Mika Nystrom Asynchronous Systems Architecture Project Department of Computer Science California Institute of Technology To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jun 21 15:43:21 1999 Delivered-To: freebsd-smp@freebsd.org Received: from noop.colo.erols.net (noop.colo.erols.net [207.96.1.150]) by hub.freebsd.org (Postfix) with ESMTP id DEACB14CA1 for ; Mon, 21 Jun 1999 15:43:17 -0700 (PDT) (envelope-from gjp@noop.colo.erols.net) Received: from localhost ([127.0.0.1] helo=noop.colo.erols.net) by noop.colo.erols.net with esmtp (Exim 2.12 #1) id 10wCmb-000Oqh-00; Mon, 21 Jun 1999 18:43:17 -0400 To: Kedar Rajadnya Cc: freebsd-smp@FreeBSD.ORG From: "Gary Palmer" Subject: Re: SMP, 4GB RAM, 4x CPU In-reply-to: Your message of "Mon, 21 Jun 1999 08:49:26 PDT." <2.2.32.19990621154926.01faf7e8@asacomputers.com> Date: Mon, 21 Jun 1999 18:43:10 -0400 Message-ID: <95522.930004990@noop.colo.erols.net> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kedar Rajadnya wrote in message ID <2.2.32.19990621154926.01faf7e8@asacomputers.com>: > >2) To get the use of 4GB dram, I am running 19990604-CURRENT. This > > has problems with 4GB dram (but I've submitted a fix), and also > > This is just a question. Do you think it would be better to use > something like an Alpha 264DP in dual-cpu format(upto 4MB cache) and 4GB RAM > rather than a quad xeon, 4GB RAM and a 32-bit bus? There is no SMP support for the AXP platform in FreeBSD Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jun 21 15:47:41 1999 Delivered-To: freebsd-smp@freebsd.org Received: from noop.colo.erols.net (noop.colo.erols.net [207.96.1.150]) by hub.freebsd.org (Postfix) with ESMTP id 14F2314CA1 for ; Mon, 21 Jun 1999 15:47:37 -0700 (PDT) (envelope-from gjp@noop.colo.erols.net) Received: from localhost ([127.0.0.1] helo=noop.colo.erols.net) by noop.colo.erols.net with esmtp (Exim 2.12 #1) id 10wCrI-000Oqy-00; Mon, 21 Jun 1999 18:48:08 -0400 To: Richard Cownie Cc: freebsd-smp@FreeBSD.ORG From: "Gary Palmer" Subject: Re: SMP, 4GB RAM, 4x CPU In-reply-to: Your message of "Mon, 21 Jun 1999 12:37:47 EDT." <99062113061000.18239@par28.ma.ikos.com> Date: Mon, 21 Jun 1999 18:48:07 -0400 Message-ID: <95539.930005287@noop.colo.erols.net> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Richard Cownie wrote in message ID <99062113061000.18239@par28.ma.ikos.com>: > Also there are rumours that Alpha performance is critically dependent > on the compiler used - i.e. the DEC compiler on Tru64 Unix (is that this > week's name ?) might give you 30% more performance than gcc. I believe GCC sucks for most RISC architectures. I could be wrong, but getting optimizing compilers for RISC is a complicated game, and I'd be real surprised if GCC managed it. I saw the same thing on the ARM platform years ago. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jun 21 17: 0: 3 1999 Delivered-To: freebsd-smp@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 246B114D76; Mon, 21 Jun 1999 16:59:57 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id QAA23167; Mon, 21 Jun 1999 16:59:57 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpd023146; Mon Jun 21 16:59:53 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id QAA16860; Mon, 21 Jun 1999 16:59:52 -0700 (MST) From: Terry Lambert Message-Id: <199906212359.QAA16860@usr01.primenet.com> Subject: Re: Multi processor support? To: dvwd@wwdg.com Date: Mon, 21 Jun 1999 23:59:52 +0000 (GMT) Cc: freebsd-questions@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG In-Reply-To: <199906190852.CAA06195@wwdg.com> from "dvwd@wwdg.com" at Jun 19, 99 02:52:23 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Also, is there any way to control what processes happen on > which cpu? Heh. That wouldn't be very symmetric... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jun 21 17:44: 4 1999 Delivered-To: freebsd-smp@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 464A614BCF; Mon, 21 Jun 1999 17:43:59 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id RAA12499; Mon, 21 Jun 1999 17:43:57 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpd012433; Mon Jun 21 17:43:51 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id RAA18994; Mon, 21 Jun 1999 17:43:50 -0700 (MST) From: Terry Lambert Message-Id: <199906220043.RAA18994@usr01.primenet.com> Subject: Re: SMP, 4GB RAM, 4x CPU To: gpalmer@FreeBSD.ORG (Gary Palmer) Date: Tue, 22 Jun 1999 00:43:50 +0000 (GMT) Cc: tich@ma.ikos.com, freebsd-smp@FreeBSD.ORG In-Reply-To: <95539.930005287@noop.colo.erols.net> from "Gary Palmer" at Jun 21, 99 06:48:07 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Also there are rumours that Alpha performance is critically dependent > > on the compiler used - i.e. the DEC compiler on Tru64 Unix (is that this > > week's name ?) might give you 30% more performance than gcc. > > I believe GCC sucks for most RISC architectures. I could be wrong, but > getting optimizing compilers for RISC is a complicated game, and I'd > be real surprised if GCC managed it. DEC (used to; haven't checked lately) have instruction scheduling code up for download on gatekeeper.dec.com. From memory, running it as an assembler preprocessor was pretty trivial. Of course, DEC may have advanced the technology without posting new code, so YMMV... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jun 21 18:22:11 1999 Delivered-To: freebsd-smp@freebsd.org Received: from 001101.zer0.org (001101.zer0.org [206.24.105.163]) by hub.freebsd.org (Postfix) with ESMTP id 5706E14C11; Mon, 21 Jun 1999 18:22:06 -0700 (PDT) (envelope-from gsutter@001101.zer0.org) Received: (from gsutter@localhost) by 001101.zer0.org (8.9.2/8.9.2) id SAA04081; Mon, 21 Jun 1999 18:20:54 -0700 (PDT) (envelope-from gsutter) Date: Mon, 21 Jun 1999 18:20:54 -0700 From: Gregory Sutter To: Terry Lambert Cc: dvwd@wwdg.com, freebsd-questions@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Multi processor support? Message-ID: <19990621182054.G73528@001101.zer0.org> References: <199906190852.CAA06195@wwdg.com> <199906212359.QAA16860@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199906212359.QAA16860@usr01.primenet.com>; from Terry Lambert on Mon, Jun 21, 1999 at 11:59:52PM +0000 Organization: Zer0 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jun 21, 1999 at 11:59:52PM +0000, Terry Lambert wrote: > > Also, is there any way to control what processes happen on > > which cpu? > > Heh. That wouldn't be very symmetric... No, but having processor affinity would be quite nice. There's nothing wrong with MP. Greg -- Gregory S. Sutter Black holes were created mailto:gsutter@pobox.com when God divided by zero. http://www.pobox.com/~gsutter/ PGP DSS public key 0x40AE3052 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jun 22 8:11: 3 1999 Delivered-To: freebsd-smp@freebsd.org Received: from par28.ma.ikos.com (par28.ma.ikos.com [137.103.105.228]) by hub.freebsd.org (Postfix) with ESMTP id 5A39C14ED0; Tue, 22 Jun 1999 08:10:58 -0700 (PDT) (envelope-from tich@par28.ma.ikos.com) Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by par28.ma.ikos.com (8.8.7/8.8.7) id LAA27657; Tue, 22 Jun 1999 11:11:13 -0400 From: Richard Cownie To: Terry Lambert , gpalmer@FreeBSD.ORG (Gary Palmer) Subject: Re: SMP, 4GB RAM, 4x CPU Date: Tue, 22 Jun 1999 10:48:44 -0400 X-Mailer: KMail [version 1.1.0] Content-Type: text/plain Cc: tich@ma.ikos.com, freebsd-smp@FreeBSD.ORG References: <199906220043.RAA18994@usr01.primenet.com> MIME-Version: 1.0 Message-Id: <99062211111300.27479@par28.ma.ikos.com> Content-Transfer-Encoding: 8bit X-KMail-Mark: Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 21 Jun 1999, Terry Lambert wrote: > DEC (used to; haven't checked lately) have instruction scheduling > code up for download on gatekeeper.dec.com. From memory, running > it as an assembler preprocessor was pretty trivial. Of course, > DEC may have advanced the technology without posting new code, so > YMMV... To expose enough parallelism to get a good instruction schedule, you probably need to do a lot of stuff earlier in the compilation, e.g. loop unrolling, traversing the expression tree in a different order for code-generation/register-allocation. In particular, once the register allocation is cast in stone you don't have very much freedom to re-order instructions. So I doubt that the assembler pre-processor makes a big difference - if you want good performance from the Alpha (and why else would you want an Alpha ?) the DEC compiler is probably the only game in town. Unless anyone's tried the assembler scheduler and has figures to suggest otherwise ? I notice that egcs (soon to be gcc-2.95) has a bunch of new instruction-scheduling stuff, maybe this will do better than the old gcc. Richard Cownie (tich@ma.ikos.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jun 22 9: 1:37 1999 Delivered-To: freebsd-smp@freebsd.org Received: from alpha.netaccess.on.ca (alpha.netaccess.on.ca [199.243.225.10]) by hub.freebsd.org (Postfix) with ESMTP id CE8B114C81; Tue, 22 Jun 1999 09:01:29 -0700 (PDT) (envelope-from rob@ControlQ.com) Received: from fatlady.controlq.com (dial203.nas.net [199.243.225.203]) by alpha.netaccess.on.ca (8.9.0/8.9.0) with SMTP id MAA17834; Tue, 22 Jun 1999 12:00:04 -0400 (EDT) Date: Tue, 22 Jun 1999 12:00:15 -0400 (EDT) From: "Robert S. Sciuk" To: Gregory Sutter Cc: Terry Lambert , dvwd@wwdg.com, freebsd-questions@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Multi processor support? In-Reply-To: <19990621182054.G73528@001101.zer0.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 21 Jun 1999, Gregory Sutter wrote: > On Mon, Jun 21, 1999 at 11:59:52PM +0000, Terry Lambert wrote: > > > Also, is there any way to control what processes happen on > > > which cpu? > > > > Heh. That wouldn't be very symmetric... > > No, but having processor affinity would be quite nice. There's > nothing wrong with MP. Processor affinity is more than nice. Work I've done on large HP boxes indicate that by putting producer/consumer processes on the same processor one avoids a lot of cache coherency issues, and increases bandwidth considerably. Admittedly, this is not true of all applications, but having the ability to have two or more processes share a processor can go a long way towards tuning application performance. I would suggest an ioctl or other API type interface, with a userland tool to assist ... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert S. Sciuk 1032 Howard Rd. PO Box 6A Ph:905 632-2466 Control-Q Research Burlington, Ont. Canada Fx:905 632-7417 rob@ControlQ.com L7R 3X5 http://www.ControlQ.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jun 22 9: 6:31 1999 Delivered-To: freebsd-smp@freebsd.org Received: from thor.tvol.net (mail.tvol.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id AAB8714C81 for ; Tue, 22 Jun 1999 09:06:26 -0700 (PDT) (envelope-from agrosky@wgate.com) Received: from dadu.eng.tvol.net (dadu.eng.tvol.net [10.32.2.13]) by thor.tvol.net (8.8.8/8.8.3) with SMTP id MAA07030; Tue, 22 Jun 1999 12:11:49 -0400 (EDT) Date: Tue, 22 Jun 1999 12:04:12 -0400 (EDT) From: Aaron Grosky X-Sender: asg@dadu.eng.tvol.net Reply-To: Aaron Grosky To: Richard Cownie Cc: freebsd-smp@FreeBSD.ORG Subject: Re: SMP, 4GB RAM, 4x CPU In-Reply-To: <99062211111300.27479@par28.ma.ikos.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, 22 Jun 1999, Richard Cownie wrote: > On Mon, 21 Jun 1999, Terry Lambert wrote: > > DEC (used to; haven't checked lately) have instruction scheduling > > code up for download on gatekeeper.dec.com. From memory, running > > it as an assembler preprocessor was pretty trivial. Of course, > > DEC may have advanced the technology without posting new code, so > > YMMV... > > To expose enough parallelism to get a good instruction schedule, > you probably need to do a lot of stuff earlier in the compilation, > e.g. loop unrolling, traversing the expression tree in a different > order for code-generation/register-allocation. In particular, > once the register allocation is cast in stone you don't have very > much freedom to re-order instructions. So I doubt that the > assembler pre-processor makes a big difference - if you want > good performance from the Alpha (and why else would you want > an Alpha ?) the DEC compiler is probably the only game in town. > > Unless anyone's tried the assembler scheduler and has figures to > suggest otherwise ? > > I notice that egcs (soon to be gcc-2.95) has a bunch of new > instruction-scheduling stuff, maybe this will do better than the > old gcc. '70s and early '80s vintage C compilers used an assembler optimizer step (input was ASCII assembly language, output was ASCII assembly language). This optimizer was able to reassign registers and rearrange code to achieve better use of registers and remove redundant memory accesses. Such an optimizer could be used to optimize RISC code (and ever *86 code), or analysis of this sort could even be build into the assembler (though then it would no longer be an assembler). In saying this, I do not disagree with Richard that doing the analysis earlier cannot achieve better optimization. I only point out that assigning the registers does not prevent major code movement nor register reassignment. Aaron Grosky agrosky@wgate.com WorldGate Communications "Internet TV Over Cable" 3220 Tillman Drive 215-633-5125 Bensalem, PA 19020 215-633-9590 (FAX) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jun 22 9:19:29 1999 Delivered-To: freebsd-smp@freebsd.org Received: from systemics.com (menger.ai [209.88.68.41]) by hub.freebsd.org (Postfix) with ESMTP id 7531B14E8D for ; Tue, 22 Jun 1999 09:19:19 -0700 (PDT) (envelope-from iang@systemics.com) Received: (from iang@localhost) by systemics.com (8.8.8/8.8.8) id MAA15934 for freebsd-smp@FreeBSD.ORG; Tue, 22 Jun 1999 12:18:55 -0400 (AST) (envelope-from iang) Date: Tue, 22 Jun 1999 12:18:55 -0400 (AST) From: Ian Grigg Message-Id: <199906221618.MAA15934@systemics.com> To: freebsd-smp@FreeBSD.ORG Subject: Re: Multi processor support? Reply-To: iang@systemics.com Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > Heh. That wouldn't be very symmetric... > > > > No, but having processor affinity would be quite nice. There's > > nothing wrong with MP. > > Processor affinity is more than nice. Work I've done on large HP boxes > indicate that by putting producer/consumer processes on the same processor > one avoids a lot of cache coherency issues, and increases bandwidth > considerably. Admittedly, this is not true of all applications, but > having the ability to have two or more processes share a processor can go > a long way towards tuning application performance. Are you making the assumption that the two processes are sharing memory for IPC? Or, maybe kernel threads? If not, I don't understand how you improve cache coherency with separate data sets. > I would suggest an > ioctl or other API type interface, with a userland tool to assist ... But, I agree with the general context. Processor affinity is nice, but should only be an option on top of SMP. I'd rather have a good SMP than an MP any day. iang To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jun 22 10: 2: 5 1999 Delivered-To: freebsd-smp@freebsd.org Received: from alpha.netaccess.on.ca (alpha.netaccess.on.ca [199.243.225.10]) by hub.freebsd.org (Postfix) with ESMTP id 29E6E152D2 for ; Tue, 22 Jun 1999 10:02:01 -0700 (PDT) (envelope-from rob@ControlQ.com) Received: from fatlady.controlq.com (dial203.nas.net [199.243.225.203]) by alpha.netaccess.on.ca (8.9.0/8.9.0) with SMTP id NAA23040; Tue, 22 Jun 1999 13:01:57 -0400 (EDT) Date: Tue, 22 Jun 1999 13:02:07 -0400 (EDT) From: "Robert S. Sciuk" To: Ian Grigg Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Multi processor support? In-Reply-To: <199906221618.MAA15934@systemics.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, 22 Jun 1999, Ian Grigg wrote: > > > > > Heh. That wouldn't be very symmetric... > > > > > > No, but having processor affinity would be quite nice. There's > > > nothing wrong with MP. > > > > Processor affinity is more than nice. Work I've done on large HP boxes > > indicate that by putting producer/consumer processes on the same processor > > one avoids a lot of cache coherency issues, and increases bandwidth > > considerably. Admittedly, this is not true of all applications, but > > having the ability to have two or more processes share a processor can go > > a long way towards tuning application performance. > > Are you making the assumption that the two processes > are sharing memory for IPC? Or, maybe kernel threads? > > If not, I don't understand how you improve cache coherency > with separate data sets. > I'm not sure that IP type socket IPC would be appreciably helped here though it is possible that Unix _domain sockets_ may be implemented using mapped memory -- I'm not sure about FreeBSD, but it is possible (likely?) Guess I could check the sources, but I don't have time right now ... in the case of applications sharing mmap'ed memory ... certainly there is a speedup on certain platforms. > > I would suggest an > > ioctl or other API type interface, with a userland tool to assist ... > > But, I agree with the general context. Processor affinity > is nice, but should only be an option on top of SMP. I'd > rather have a good SMP than an MP any day. I can't disagree 8-). Cheers, Rob. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert S. Sciuk 1032 Howard Rd. PO Box 6A Ph:905 632-2466 Control-Q Research Burlington, Ont. Canada Fx:905 632-7417 rob@ControlQ.com L7R 3X5 http://www.ControlQ.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jun 22 11:21: 0 1999 Delivered-To: freebsd-smp@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id DC9C714D4D for ; Tue, 22 Jun 1999 11:20:57 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (phoenix.cs.rpi.edu [128.113.96.153]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id OAA16702 for ; Tue, 22 Jun 1999 14:20:56 -0400 (EDT) Message-Id: <199906221820.OAA16702@cs.rpi.edu> To: freebsd-smp@freebsd.org Subject: Re: Call to arms..-SMP Date: Tue, 22 Jun 1999 14:20:56 -0400 From: "David E. Cross" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It was mentioned awhile ago on -hackers or -current (I forget which), that until now FreeBSD's SMP had been evolutionary, what we need is revolutionary. It went on to describe a method that uses mutex-es and message passing within the kernel. How hard would that be to impliment? I don't forsee the recent discussion about per IRQ threads as being the answer to the question. FreeBSD has always been a bit behind because we try to do things right. I would really like to see something as advanced as a threaded kernel with mutex-es and the like, and I think that would clearly give us the very best performance. What is the status of any mods to the SMP foundation to accomidate either setup? -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jun 22 11:35:48 1999 Delivered-To: freebsd-smp@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 8810A15480; Tue, 22 Jun 1999 11:35:36 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id LAA21971; Tue, 22 Jun 1999 11:35:35 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd021941; Tue Jun 22 11:35:27 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA25521; Tue, 22 Jun 1999 11:35:27 -0700 (MST) From: Terry Lambert Message-Id: <199906221835.LAA25521@usr05.primenet.com> Subject: Re: Multi processor support? To: gsutter@pobox.com (Gregory Sutter) Date: Tue, 22 Jun 1999 18:35:27 +0000 (GMT) Cc: tlambert@primenet.com, dvwd@wwdg.com, freebsd-questions@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG In-Reply-To: <19990621182054.G73528@001101.zer0.org> from "Gregory Sutter" at Jun 21, 99 06:20:54 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > Also, is there any way to control what processes happen on > > > which cpu? > > > > Heh. That wouldn't be very symmetric... > > No, but having processor affinity would be quite nice. There's > nothing wrong with MP. Processor afinnity is not the same thing as locking a process to a CPU (affinity means that it prefers to stay on the same CPU, as opposed to being forced to stay on the same CPU no matter how loaded that CPU gets vs. the relative cost of a cache bust. Unless you are engaged in L1/L2 cache-busting behaviour (not possible with one process), then locking to a particular CPU buys you only assymetry (kind of like wearing a jaunty hat). INRE: The previous question about one FORTRAN process using multiple CPU's in Linux being better than that on FreeBSD: not possible at the present time. The point is that in order for a single program to benefit from SMP, you must either engage in static scheduling, e.g.: | Compile-time Partitioning and Scheduling of Parallel Programs | V. Sarkar and J. Hennessy | Proceedings of the SIGPLAN '88 Symposium on Compiler | Construction, 1986, pages 17-26 | Compile-Rime Scheduling and Assignment of Data-Flow Program | Graphs | S. Ha and E.A. Lee | IEEE Transactions on Computers, November 1991, pages 1225-1238 Or you must engage in task granularization and partitioning, e.g.: | On the Granularity and Clustering of Directed Acyclic Task | Graphs | A. Gerasoulis and T. Yang | IEEE Transactions on Parallel and Distributed Systems, June | 1993, pages 686-701 | Grain Size Determination for Parallel Processing | B. Kruatrachue and T. Lewis | IEEE Software, January 1988, pages 23-32 | Lazy Task Creation: A Technique for increasing Granularity | of Parallel Programs | E. Mohr, D.A. Kranz, and R.H. Halstead, Jr. | IEEE Transactions on Parallel and Distributed Systems, July | 1991, pages 264-280 (Note: this last describes the method used for lazy kernel thread creation utilized by BSDI -- only 8 years behind the literature). Or you must use scheduling tools, e.g.: | PARSA: A Parallel Program Software Development Tool | B. Shirazi et al. | Proceedings 1994 Symposium on Assessment of Quality Software | Development Tools, 1994, pages 96-111 | Parafrase-2: An Environment for Parallelizing, Partitioning, | Synchronizing, ans Scheduling Programs on Multiprocessors | C.D. Polychronopoulos et al. | Proceedings 1989 International Conference on Parallel | Processing In other words, you need help from your tools, and the GNU FORTRAN compiler just isn't going to cut it. Neither is a commercial FORTRAN compiler without explicit knowledge of the task architecture implemetnation so that it know where to do the trade-offs. The best you are going to get is explicit division of tasks between multiple processes. At *that* point (and *only* then) does CPU affinity become a real issue. Even so, it's not an issue addressed (IMO) by the Linux SMP implementation (any more than the FreeBSD or BSDI implementations). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jun 22 12: 0:18 1999 Delivered-To: freebsd-smp@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 498591548B for ; Tue, 22 Jun 1999 12:00:15 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id MAA01797; Tue, 22 Jun 1999 12:00:12 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd001762; Tue Jun 22 12:00:05 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id MAA26496; Tue, 22 Jun 1999 12:00:04 -0700 (MST) From: Terry Lambert Message-Id: <199906221900.MAA26496@usr05.primenet.com> Subject: Re: SMP, 4GB RAM, 4x CPU To: agrosky@wgate.com Date: Tue, 22 Jun 1999 19:00:04 +0000 (GMT) Cc: tich@ma.ikos.com, freebsd-smp@FreeBSD.ORG In-Reply-To: from "Aaron Grosky" at Jun 22, 99 12:04:12 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > '70s and early '80s vintage C compilers used an assembler optimizer step > (input was ASCII assembly language, output was ASCII assembly language). > This optimizer was able to reassign registers and rearrange code to achieve > better use of registers and remove redundant memory accesses. Such an > optimizer could be used to optimize RISC code (and ever *86 code), or > analysis of this sort could even be build into the assembler (though then > it would no longer be an assembler). This is the stuff that was (is?) downloadable from gatekeeper. > In saying this, I do not disagree with Richard that doing the analysis > earlier cannot achieve better optimization. I only point out that > assigning the registers does not prevent major code movement nor register > reassignment. Definitely agreed. It's better to have the stuff in the compiler itself. However, the compiler needs knowledge of the architecture on which the code will run (task architexture, not processor) for this to be a real win at all. One thing that makes the assembler preprocessor stuff really dangerous these days is the default assumption of non-volatile for external references and register promotions. I think you would need a very, very large peephole in order to not break some of the ANSI C optimization assumptions. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jun 22 12: 7:37 1999 Delivered-To: freebsd-smp@freebsd.org Received: from argus.tfs.net (host1-246.birch.net [216.212.1.246]) by hub.freebsd.org (Postfix) with ESMTP id 85B60157C4 for ; Tue, 22 Jun 1999 12:07:26 -0700 (PDT) (envelope-from jbryant@argus.tfs.net) Received: (from jbryant@localhost) by argus.tfs.net (8.9.3/8.8.5) id OAA95303; Tue, 22 Jun 1999 14:07:04 -0500 (CDT) From: Jim Bryant Message-Id: <199906221907.OAA95303@argus.tfs.net> Subject: Re: Multi processor support? In-Reply-To: from "Robert S. Sciuk" at "Jun 22, 99 12:00:15 pm" To: rob@ControlQ.com (Robert S. Sciuk) Date: Tue, 22 Jun 1999 14:07:03 -0500 (CDT) Cc: freebsd-smp@freebsd.org Reply-To: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-files: The truth is that the X-Files is fiction X-Republican: The best kind!!! X-Operating-System: FreeBSD 4.0-CURRENT #31: Thu Apr 8 10:40:17 CDT 1999 X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In reply: > On Mon, 21 Jun 1999, Gregory Sutter wrote: > > > On Mon, Jun 21, 1999 at 11:59:52PM +0000, Terry Lambert wrote: > > > > Also, is there any way to control what processes happen on > > > > which cpu? > > > > > > Heh. That wouldn't be very symmetric... > > > > No, but having processor affinity would be quite nice. There's > > nothing wrong with MP. > > Processor affinity is more than nice. Work I've done on large HP boxes > indicate that by putting producer/consumer processes on the same processor > one avoids a lot of cache coherency issues, and increases bandwidth > considerably. Admittedly, this is not true of all applications, but > having the ability to have two or more processes share a processor can go > a long way towards tuning application performance. I would suggest an > ioctl or other API type interface, with a userland tool to assist ... good idea. Tandem, and Convex [now part of HP], are two other companies that explicitly allow you to define such overrides as the max number of cpu's a process can run on, the specific cpus to run on, etc... This can be very handy in hand optimization of production systems. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jun 22 18:11:48 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mail.rdc1.sfba.home.com (ha1.rdc1.sfba.home.com [24.0.0.66]) by hub.freebsd.org (Postfix) with ESMTP id 1141014BD4; Tue, 22 Jun 1999 18:11:44 -0700 (PDT) (envelope-from adsharma@c62443-a.frmt1.sfba.home.com) Received: from c62443-a.frmt1.sfba.home.com ([24.0.69.165]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990623011144.RXEY8807.mail.rdc1.sfba.home.com@c62443-a.frmt1.sfba.home.com>; Tue, 22 Jun 1999 18:11:44 -0700 Received: (from adsharma@localhost) by c62443-a.frmt1.sfba.home.com (8.8.7/8.8.7) id SAA22415; Tue, 22 Jun 1999 18:11:39 -0700 To: freebsd-questions@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Multi processor support? References: <199906221835.LAA25521@usr05.primenet.com> From: Arun Sharma Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: 22 Jun 1999 18:11:39 -0700 In-Reply-To: Terry Lambert's message of "Tue, 22 Jun 1999 18:35:27 +0000 (GMT)" Message-ID: Lines: 25 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry Lambert writes: > The best you are going to get is explicit division of tasks > between multiple processes. At *that* point (and *only* then) > does CPU affinity become a real issue. Even so, it's not an > issue addressed (IMO) by the Linux SMP implementation (any > more than the FreeBSD or BSDI implementations). Linux scheduler does implement processor affinity to some extent: #ifdef __SMP__ /* Give a largish advantage to the same processor... */ /* (this is equivalent to penalizing other processors) */ if (p->processor == this_cpu) weight += PROC_CHANGE_PENALTY; #endif A better way to do this would be to split the runnable process queues into per processor queues (ref: Digital's SMP implementation). Also, the ability to have multiple threads executing in a single address space, scheduled on different processors simultaneously is very significant. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Jun 23 10:27:59 1999 Delivered-To: freebsd-smp@freebsd.org Received: from ares.cs.Virginia.EDU (ares.cs.Virginia.EDU [128.143.136.41]) by hub.freebsd.org (Postfix) with ESMTP id 3C1E614E06 for ; Wed, 23 Jun 1999 10:27:56 -0700 (PDT) (envelope-from chapin@cs.virginia.edu) Received: from cs.virginia.edu (mamba.cs.Virginia.EDU [128.143.137.15]) by ares.cs.Virginia.EDU (8.9.2/8.9.2/UVACS-1999030200) with ESMTP id NAA11160; Wed, 23 Jun 1999 13:27:08 -0400 (EDT) Message-Id: <199906231727.NAA11160@ares.cs.Virginia.EDU> Reply-To: chapin@cs.virginia.edu From: chapin@cs.virginia.edu (Steve Chapin) To: "M. L. Dodson" Cc: Richard Cownie , Kedar Rajadnya , freebsd-smp@freebsd.org Zevon-of-the-day: Jeannie Needs a Shooter Subject: Re: SMP, 4GB RAM, 4x CPU In-reply-to: Your message of Mon, 21 Jun 1999 15:26:23 CDT. <199906212026.PAA15925@beowulf.utmb.edu> Date: Wed, 23 Jun 1999 13:27:06 -0400 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > So tell us: What's the trick compiler suite on Alpha (both > fortran and c, preferably)? I asked our apps person what she's currently using. Separate from this, we did some benchmarking using the Digital Unix, er, Compaq compilers, and they were much better than g77. We don't yet have them for production use. For C/C++, we're using egcs. > Mostly apps use the native Fortran compiler on whatever > platform, and we hope it will link correctly with gcc-compiled > libraries. So on AIX we use XLF. I have not really used other > platforms other than Linux, but we'd use the vendor Fortran if > at all possible. Under Linux, we use g77 if we can. However, > many apps use extensions and/or Fortran 90 features not > supported by g77, so we have to use an alternative. That's > nothing much on Alpha (we are hoping for the Compaq compilers > Real Soon Now) or the Portland Group compiler on Intel. sc -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Jun 24 4:33:36 1999 Delivered-To: freebsd-smp@freebsd.org Received: from enterprise.sanyusan.se (enterprise.sanyusan.se [195.24.160.51]) by hub.freebsd.org (Postfix) with ESMTP id 6551215261 for ; Thu, 24 Jun 1999 04:33:31 -0700 (PDT) (envelope-from anders@enterprise.sanyusan.se) Received: (from anders@localhost) by enterprise.sanyusan.se (8.9.3/8.9.3) id NAA10248; Thu, 24 Jun 1999 13:30:51 +0200 (CEST) (envelope-from anders) Date: Thu, 24 Jun 1999 13:30:51 +0200 From: Anders Andersson To: Aaron Smith Cc: freebsd-smp@freebsd.org Subject: Re: P2B-DS and its statclock/APM/whatever Message-ID: <19990624133051.A10209@sanyusan.se> References: <19990619205743.A511@bnc.net> <199906191940.MAA94507@sigma.veritas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95.6i In-Reply-To: =?iso-8859-1?Q?=3C199906191940=2EMAA94507=40sigma=2Everitas=2Ecom=3E=3B_?= =?iso-8859-1?Q?from_Aaron_Smith_on_L=F6r=2C_Jun_19=2C_1999_at_12:40:27pm?= =?iso-8859-1?Q?_-0700?= Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Aaron Smith (aaron-fbsd@mutex.org) [990619 21:42]: > > don't downgrade, just try this patch from Tor Egge. it worked great for my > P2B-DS (bios rev 1008). > > Aaron I have a P2B-DS (bios rev. 1008) running 3.2-STABLE also. I have read the threads in this list but I have not tried Tor Egge's patch yet. Although enabling apm in the kernel did not help to get top CPU status and so on. Is Tor Egge's patch for -STABLE? and is this the only way to go with these motherboards? Cheers Anders -- -------------------------------------------------------- Anders Andersson anders@sanyusan.se Sanyusan International AB http://www.sanyusan.se/ Västgötagatan 11 Tel: +46-(0)31-168730 411 39 Gothenburg, SWEDEN Fax: +46-(0)31-209361 -------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Jun 24 5:44:42 1999 Delivered-To: freebsd-smp@freebsd.org Received: from acetylene.vapornet.net (acetylene.vapornet.net [209.100.218.11]) by hub.freebsd.org (Postfix) with ESMTP id 93A8514F00 for ; Thu, 24 Jun 1999 05:44:40 -0700 (PDT) (envelope-from john@vapornet.net) Received: from datapit.home.vapornet.net (vapornet.xnet.com [205.243.141.107]) by acetylene.vapornet.net (8.9.3/8.9.3/VaporServer 2.01) with ESMTP id HAA47046; Thu, 24 Jun 1999 07:44:39 -0500 (CDT) (envelope from: john@vapornet.net) Received: from habanero.chili-pepper.net (habanero.chili-pepper.net [192.168.0.11]) by datapit.home.vapornet.net (8.9.3/8.9.3/VaporServer 1.4) with ESMTP id HAA06858; Thu, 24 Jun 1999 07:44:37 -0500 (CDT) (envelope from: john@vapornet.net) Received: (from john@localhost) by habanero.chili-pepper.net (8.9.3/8.9.3/VaporClient v3.1) id HAA05222; Thu, 24 Jun 1999 07:44:33 -0500 (CDT) (envelope from: john@vapornet.net) From: John Preisler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 24 Jun 1999 07:44:33 -0500 (CDT) To: Anders Andersson Cc: Aaron Smith , freebsd-smp@FreeBSD.ORG Subject: Re: P2B-DS and its statclock/APM/whatever In-Reply-To: <19990624133051.A10209@sanyusan.se> References: <19990619205743.A511@bnc.net> <199906191940.MAA94507@sigma.veritas.com> <19990624133051.A10209@sanyusan.se> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14194.9826.956554.290601@habanero.chili-pepper.net> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What line did you add? # The flags takes the following meaning for apm0: # 0x0020 Statclock is broken. # 0x0011 Limit APM protocol to 1.1 or 1.0 # 0x0010 Limit APM protocol to 1.0 # If apm is omitted, some systems require sysctl -w kern.timcounter.method=1 # for correct timekeeping. I find that device apm0 at nexus? flags 0x20 works like a champ for my board with bios v1008. Compile in apm support AND flag the statclock as broken. and yes you need apm enabled in the bios as well. simply having it in your kernel and not turning it on in the bios is not enough. dont forget to cd /dev ; sh MAKEDEV apm0 just in case Anders Andersson writes: > * Aaron Smith (aaron-fbsd@mutex.org) [990619 21:42]: > > > > don't downgrade, just try this patch from Tor Egge. it worked great for my > > P2B-DS (bios rev 1008). > > > > Aaron > > I have a P2B-DS (bios rev. 1008) running 3.2-STABLE also. > > I have read the threads in this list but I have not tried Tor Egge's patch > yet. Although enabling apm in the kernel did not help to get top CPU > status and so on. > > Is Tor Egge's patch for -STABLE? and is this the only way to go with > these motherboards? > > Cheers > > Anders > -- > > > -------------------------------------------------------- > Anders Andersson anders@sanyusan.se > Sanyusan International AB http://www.sanyusan.se/ > Vstgtagatan 11 Tel: +46-(0)31-168730 > 411 39 Gothenburg, SWEDEN Fax: +46-(0)31-209361 > -------------------------------------------------------- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message -- John Preisler president, VaporNet Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Jun 24 14: 8:33 1999 Delivered-To: freebsd-smp@freebsd.org Received: from andrsn.stanford.edu (andrsn.Stanford.EDU [36.33.0.163]) by hub.freebsd.org (Postfix) with ESMTP id 94DC415284 for ; Thu, 24 Jun 1999 14:08:29 -0700 (PDT) (envelope-from andrsn@andrsn.stanford.edu) Received: from localhost (andrsn@localhost.stanford.edu [127.0.0.1]) by andrsn.stanford.edu (8.9.1/8.9.1) with SMTP id OAA21027 for ; Thu, 24 Jun 1999 14:01:29 -0700 (PDT) Date: Thu, 24 Jun 1999 14:01:29 -0700 (PDT) From: Annelise Anderson To: smp@freebsd.org Subject: Bogus MP Table 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'm getting a message about a bogus MP table since I added a second (isa 3COM509B) ethernet card and took it out of pnp mode. Maybe I should get a different (pci) ethernet card? Here's the mptable output. Annelise =============================================================================== MPTable, version 2.0.15 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f6e60 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0xda mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f6a50 signature: 'PCMP' base table length: 260 version: 1.1 checksum: 0x2e OEM ID: 'OEM00000' Product ID: 'PROD00000000' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 24 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 1 0x11 BSP, usable 6 5 3 0x183fbff 0 0x11 AP, usable 6 5 3 0x183fbff -- Bus: Bus ID Type 0 PCI 1 PCI 2 ISA -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT conforms conforms 2 0 2 0 INT conforms conforms 2 1 2 1 INT conforms conforms 2 0 2 2 INT conforms conforms 2 3 2 3 INT conforms conforms 2 4 2 4 INT conforms conforms 2 6 2 6 INT conforms conforms 2 7 2 7 INT conforms conforms 2 8 2 8 INT conforms conforms 2 10 2 10 INT conforms conforms 2 11 2 11 INT conforms conforms 2 12 2 12 INT conforms conforms 2 14 2 14 INT conforms conforms 2 15 2 15 INT active-lo level 2 5 2 16 INT active-lo level 2 9 2 17 INT active-lo level 2 9 2 19 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 2 0 255 0 NMI active-hi edge 2 0 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 =============================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Jun 25 0: 8: 9 1999 Delivered-To: freebsd-smp@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 78F0E14D0E for ; Fri, 25 Jun 1999 00:08:06 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id AAA10397 for ; Fri, 25 Jun 1999 00:08:05 -0700 (PDT) Date: Fri, 25 Jun 1999 00:08:05 -0700 (PDT) From: Julian Elischer To: smp@freebsd.org Subject: Re: Call to arms..-SMP (fwd) 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 ---------- Forwarded message ---------- Date: Thu, 24 Jun 1999 17:16:22 -0400 (EDT) From: Luoqi Chen To: alc@cs.rice.edu, bde@freebsd.org, dyson@iquest.net, julian@whistle.com, luoqi@freebsd.org Subject: Re: Call to arms..-SMP > I'd like to make a modest proposal to get things started: Can we modify > the various kernel entry points so that they don't acquire the giant > lock(s) by default and instead parameterize the decision. In other words, > somewhere associate a bit/flag with each trap/syscall, etc. that > determines whether or not the lock is acquired. This would make > incremental multithreading of the kernel easy, which I think is > important. There's a fair bit of low-hanging fruit that this would > enable us to pick. For example, there are a number of syscalls > in the VM system that I could almost immediately enable multithreading of. > I say let's do this. > Ideas? Code? I'm asking because I think most of you know the low-level > assembly glue that would have to be modified better than I do right > now. > Not much assembly is need. All we need to do is to make SYSCALL_LOCK a nop, and handle the locking in syscall() the C function. > Alan > -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Jun 25 0: 8:35 1999 Delivered-To: freebsd-smp@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 5ABBA14D77 for ; Fri, 25 Jun 1999 00:08:28 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id AAA10404 for ; Fri, 25 Jun 1999 00:08:26 -0700 (PDT) Date: Fri, 25 Jun 1999 00:08:26 -0700 (PDT) From: Julian Elischer To: smp@freebsd.org Subject: Re: Call to arms..-SMP (fwd) 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 ---------- Forwarded message ---------- Date: Thu, 24 Jun 1999 17:31:13 -0500 From: Alan Cox To: Luoqi Chen Cc: alc@cs.rice.edu, bde@freebsd.org, dyson@iquest.net, julian@whistle.com, luoqi@freebsd.org Subject: Re: Call to arms..-SMP On Thu, Jun 24, 1999 at 05:16:22PM -0400, Luoqi Chen wrote: > Not much assembly is need. All we need to do is to make SYSCALL_LOCK a nop, > and handle the locking in syscall() the C function. > So where does the unlock occur currently for a syscall? Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Jun 25 0: 8:53 1999 Delivered-To: freebsd-smp@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 1F71F14DC4 for ; Fri, 25 Jun 1999 00:08:48 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id AAA10413 for ; Fri, 25 Jun 1999 00:08:48 -0700 (PDT) Date: Fri, 25 Jun 1999 00:08:47 -0700 (PDT) From: Julian Elischer To: smp@freebsd.org Subject: Re: Call to arms..-SMP (fwd) 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 FYI for the group ---------- Forwarded message ---------- Date: Thu, 24 Jun 1999 22:55:29 -0500 From: Alan Cox To: Luoqi Chen Cc: alc@cs.rice.edu, bde@freebsd.org, dyson@iquest.net, julian@whistle.com, luoqi@freebsd.org Subject: Re: Call to arms..-SMP Here's a starting point ... the problem is that the unlock is performed in doreti, which is used by everything and not just syscalls. For all the pretty differentiation of fpu_lock, align_lock, etc. doreti knows that these are all really the same lock. Alan Index: i386/i386/trap.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v retrieving revision 1.139 diff -c -r1.139 trap.c *** trap.c 1999/06/18 14:32:16 1.139 --- trap.c 1999/06/24 23:30:38 *************** *** 1036,1041 **** --- 1036,1044 ---- else callp = &p->p_sysent->sv_table[code]; + if ( ! callp->sy_locked) + get_syscall_lock(); + if (params && (i = callp->sy_narg * sizeof(int)) && (error = copyin(params, (caddr_t)args, (u_int)i))) { #ifdef KTRACE Index: i386/include/lock.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/lock.h,v retrieving revision 1.6 diff -c -r1.6 lock.h *** lock.h 1998/04/06 11:38:17 1.6 --- lock.h 1999/06/24 23:22:32 *************** *** 43,49 **** #define FPU_LOCK call _get_fpu_lock #define ALIGN_LOCK call _get_align_lock ! #define SYSCALL_LOCK call _get_syscall_lock #define ALTSYSCALL_LOCK call _get_altsyscall_lock /* --- 43,49 ---- #define FPU_LOCK call _get_fpu_lock #define ALIGN_LOCK call _get_align_lock ! #define SYSCALL_LOCK #define ALTSYSCALL_LOCK call _get_altsyscall_lock /* Index: kern/init_sysent.c =================================================================== RCS file: /home/ncvs/src/sys/kern/init_sysent.c,v retrieving revision 1.66 diff -c -r1.66 init_sysent.c *** init_sysent.c 1999/05/13 09:12:50 1.66 --- init_sysent.c 1999/06/25 00:11:04 *************** *** 39,45 **** { 1, (sy_call_t *)obreak }, /* 17 = break */ { 3, (sy_call_t *)getfsstat }, /* 18 = getfsstat */ { compat(3,lseek) }, /* 19 = old lseek */ ! { 0, (sy_call_t *)getpid }, /* 20 = getpid */ { 4, (sy_call_t *)mount }, /* 21 = mount */ { 2, (sy_call_t *)unmount }, /* 22 = unmount */ { 1, (sy_call_t *)setuid }, /* 23 = setuid */ --- 39,45 ---- { 1, (sy_call_t *)obreak }, /* 17 = break */ { 3, (sy_call_t *)getfsstat }, /* 18 = getfsstat */ { compat(3,lseek) }, /* 19 = old lseek */ ! { 0, (sy_call_t *)getpid, 1 }, /* 20 = getpid */ { 4, (sy_call_t *)mount }, /* 21 = mount */ { 2, (sy_call_t *)unmount }, /* 22 = unmount */ { 1, (sy_call_t *)setuid }, /* 23 = setuid */ *************** *** 58,64 **** { 0, (sy_call_t *)sync }, /* 36 = sync */ { 2, (sy_call_t *)kill }, /* 37 = kill */ { compat(2,stat) }, /* 38 = old stat */ ! { 0, (sy_call_t *)getppid }, /* 39 = getppid */ { compat(2,lstat) }, /* 40 = old lstat */ { 1, (sy_call_t *)dup }, /* 41 = dup */ { 0, (sy_call_t *)pipe }, /* 42 = pipe */ --- 58,64 ---- { 0, (sy_call_t *)sync }, /* 36 = sync */ { 2, (sy_call_t *)kill }, /* 37 = kill */ { compat(2,stat) }, /* 38 = old stat */ ! { 0, (sy_call_t *)getppid, 1 }, /* 39 = getppid */ { compat(2,lstat) }, /* 40 = old lstat */ { 1, (sy_call_t *)dup }, /* 41 = dup */ { 0, (sy_call_t *)pipe }, /* 42 = pipe */ *************** *** 66,72 **** { 4, (sy_call_t *)profil }, /* 44 = profil */ { 4, (sy_call_t *)ktrace }, /* 45 = ktrace */ { 3, (sy_call_t *)sigaction }, /* 46 = sigaction */ ! { 0, (sy_call_t *)getgid }, /* 47 = getgid */ { 2, (sy_call_t *)sigprocmask }, /* 48 = sigprocmask */ { 2, (sy_call_t *)getlogin }, /* 49 = getlogin */ { 1, (sy_call_t *)setlogin }, /* 50 = setlogin */ --- 66,72 ---- { 4, (sy_call_t *)profil }, /* 44 = profil */ { 4, (sy_call_t *)ktrace }, /* 45 = ktrace */ { 3, (sy_call_t *)sigaction }, /* 46 = sigaction */ ! { 0, (sy_call_t *)getgid, 1 }, /* 47 = getgid */ { 2, (sy_call_t *)sigprocmask }, /* 48 = sigprocmask */ { 2, (sy_call_t *)getlogin }, /* 49 = getlogin */ { 1, (sy_call_t *)setlogin }, /* 50 = setlogin */ *************** *** 100,106 **** { 3, (sy_call_t *)mincore }, /* 78 = mincore */ { 2, (sy_call_t *)getgroups }, /* 79 = getgroups */ { 2, (sy_call_t *)setgroups }, /* 80 = setgroups */ ! { 0, (sy_call_t *)getpgrp }, /* 81 = getpgrp */ { 2, (sy_call_t *)setpgid }, /* 82 = setpgid */ { 3, (sy_call_t *)setitimer }, /* 83 = setitimer */ { compat(0,wait) }, /* 84 = old wait */ --- 100,106 ---- { 3, (sy_call_t *)mincore }, /* 78 = mincore */ { 2, (sy_call_t *)getgroups }, /* 79 = getgroups */ { 2, (sy_call_t *)setgroups }, /* 80 = setgroups */ ! { 0, (sy_call_t *)getpgrp, 1 }, /* 81 = getpgrp */ { 2, (sy_call_t *)setpgid }, /* 82 = setpgid */ { 3, (sy_call_t *)setitimer }, /* 83 = setitimer */ { compat(0,wait) }, /* 84 = old wait */ Index: sys/sysent.h =================================================================== RCS file: /home/ncvs/src/sys/sys/sysent.h,v retrieving revision 1.20 diff -c -r1.20 sysent.h *** sysent.h 1999/01/09 14:15:40 1.20 --- sysent.h 1999/06/24 23:20:21 *************** *** 43,48 **** --- 43,49 ---- struct sysent { /* system call table */ int sy_narg; /* number of arguments */ sy_call_t *sy_call; /* implementing function */ + int sy_locked; }; #define SCARG(p,k) ((p)->k) /* get arg from args pointer */ /* placeholder till we integrate rest of lite2 syscallargs changes XXX */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Jun 25 0: 9: 9 1999 Delivered-To: freebsd-smp@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 5B3E414D0E for ; Fri, 25 Jun 1999 00:09:05 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id AAA10422 for ; Fri, 25 Jun 1999 00:09:05 -0700 (PDT) Date: Fri, 25 Jun 1999 00:09:05 -0700 (PDT) From: Julian Elischer To: smp@freebsd.org Subject: Re: Call to arms..-SMP (fwd) 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 ---------- Forwarded message ---------- Date: Fri, 25 Jun 1999 01:39:34 -0500 From: Alan Cox To: Luoqi Chen Cc: dyson@iquest.net, julian@whistle.com Subject: Re: Call to arms..-SMP _cpl is a problem. I noticed this because performance went to hell. John, have you thought about this before? Can/should _cpl be a per-processor variable? MPLOCKED incl _cnt+V_SYSCALL ECPL_LOCK #ifdef CPL_AND_CML movl $SWI_AST_MASK,_cml #else movl $SWI_AST_MASK,_cpl #endif ECPL_UNLOCK call _syscall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Jun 25 0:17:50 1999 Delivered-To: freebsd-smp@freebsd.org Received: from dingo.cdrom.com (castles520.castles.com [208.214.165.84]) by hub.freebsd.org (Postfix) with ESMTP id CA09514D0E for ; Fri, 25 Jun 1999 00:17:47 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id AAA00587; Fri, 25 Jun 1999 00:14:14 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199906250714.AAA00587@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Julian Elischer Cc: smp@freebsd.org Subject: Re: Call to arms..-SMP (fwd) In-reply-to: Your message of "Fri, 25 Jun 1999 00:08:05 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jun 1999 00:14:13 -0700 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > I'd like to make a modest proposal to get things started: Can we modify > > the various kernel entry points so that they don't acquire the giant > > lock(s) by default and instead parameterize the decision. In other words, > > somewhere associate a bit/flag with each trap/syscall, etc. that > > determines whether or not the lock is acquired. This would make > > incremental multithreading of the kernel easy, which I think is > > important. There's a fair bit of low-hanging fruit that this would > > enable us to pick. For example, there are a number of syscalls > > in the VM system that I could almost immediately enable multithreading of. > > > I say let's do this. I'm not entirely sure that dissociating the lock status of a syscall from the implementation of the syscall is a good idea. If we assume that the new implementation of the lock involves counting (so that one syscall may chain to another with the lock DTRT), then I would feel even more strongly about inlining the lock acquisition. This would also make moving it around a lot easier. > Not much assembly is need. All we need to do is to make SYSCALL_LOCK a nop, > and handle the locking in syscall() the C function. Don't even do it here; put the lock acquisitions/releases in the syscall implementation functions themselves. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Jun 25 9:52:13 1999 Delivered-To: freebsd-smp@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 8DBCF1572C for ; Fri, 25 Jun 1999 09:52:11 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id JAA25582; Fri, 25 Jun 1999 09:52:10 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpd025533; Fri Jun 25 09:52:06 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id JAA25770; Fri, 25 Jun 1999 09:52:05 -0700 (MST) From: Terry Lambert Message-Id: <199906251652.JAA25770@usr01.primenet.com> Subject: Re: Call to arms..-SMP (fwd) To: mike@smith.net.au (Mike Smith) Date: Fri, 25 Jun 1999 16:52:03 +0000 (GMT) Cc: julian@whistle.com, smp@FreeBSD.ORG In-Reply-To: <199906250714.AAA00587@dingo.cdrom.com> from "Mike Smith" at Jun 25, 99 00:14:13 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Not much assembly is need. All we need to do is to make SYSCALL_LOCK a nop, > > and handle the locking in syscall() the C function. > > Don't even do it here; put the lock acquisitions/releases in the > syscall implementation functions themselves. Last time I looked, portions of the trap code and the signal trampoline were not process reentrant. This should not be done until they are, since a user space call conversion scheduler or use of async system calls (e.g. aioread) that occurred simultaneously with a subsequent call could result in a kernel stack corruption of the already pending async call. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Jun 25 11: 2:31 1999 Delivered-To: freebsd-smp@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 706C21559E for ; Fri, 25 Jun 1999 11:02:05 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id LAA30938 for ; Fri, 25 Jun 1999 11:02:04 -0700 (PDT) Date: Fri, 25 Jun 1999 11:02:04 -0700 (PDT) From: Julian Elischer To: smp@freebsd.org Subject: Re: Call to arms..-SMP (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2067406009-930333724=:3553" Content-ID: Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-2067406009-930333724=:3553 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: ---------- Forwarded message ---------- Date: Fri, 25 Jun 1999 02:06:13 -0500 (EST) From: "John S. Dyson" To: Alan Cox Cc: luoqi@watermarkgroup.com, dyson@iquest.net, julian@whistle.com Subject: Re: Call to arms..-SMP > _cpl is a problem. I noticed this because performance > went to hell. John, have you thought about this before? > Can/should _cpl be a per-processor variable? > > MPLOCKED incl _cnt+V_SYSCALL > ECPL_LOCK > #ifdef CPL_AND_CML > movl $SWI_AST_MASK,_cml > #else > movl $SWI_AST_MASK,_cpl > #endif > ECPL_UNLOCK > call _syscall > I have a slightly different scheme for the code that you quote. Note that mine is NOT necessarily better, so here is my current version. This begs your question, but I'll try to get back with you when I am lucid. Note that the interrupt code that I am using is MUCH shorter code space wise, once compiled. Again, this isn't responding to your issue. First response to your question is that given a global lock, _cpl should logically be a single variable. CPL itself is a lame concept (IMO) once you are beyond the actual interrupt routine itself. IMO, the actual driver should be a RT scheduleable entity. It seems that the worst of the benchmark perf is due to the network code not being able to run concurrently. What about (for short term a** covering) working the network code so that it can somehow run concurrently with multiple socket reads and writes? I don't know what would be necessary. BTW, I have put rel_mplock, get_mplock around the vm_page_copy and vm_page_zero routines also. I don't know if it really helps, but looks benign. (Note that the pmap manipulations have to be per-processor for that to work. It is true for my current pmap code, but I forget about -current.) John --0-2067406009-930333724=:3553 Content-Type: *UNKNOWN*/X-SH Content-ID: Content-Description: /sys/i386/i386/exception.s /*- * Copyright (c) 1990 The Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $Id: exception.s,v 1.55 1998/08/10 19:41:07 bde Exp $ */ #include "npx.h" #include "opt_vm86.h" #include #include #include #include #include #ifdef SMP #include /** CPL_AND_CML, REAL_ */ #endif #include "assym.s" #ifndef SMP #define ECPL_LOCK /* make these nops */ #define ECPL_UNLOCK #define ICPL_LOCK #define ICPL_UNLOCK #define FAST_ICPL_UNLOCK #define AICPL_LOCK #define AICPL_UNLOCK #define AVCPL_LOCK #define AVCPL_UNLOCK #endif /* SMP */ #define KCSEL 0x08 /* kernel code selector */ #define KDSEL 0x10 /* kernel data selector */ #define SEL_RPL_MASK 0x0003 #define TRAPF_CS_OFF (13 * 4) .text /*****************************************************************************/ /* Trap handling */ /*****************************************************************************/ /* * Trap and fault vector routines */ #define IDTVEC(name) ALIGN_TEXT; .globl __CONCAT(_X,name); __CONCAT(_X,name): #define TRAP(a) pushl $(a) ; jmp _alltraps /* * XXX - debugger traps are now interrupt gates so at least bdb doesn't lose * control. The sti's give the standard losing behaviour for ddb and kgdb. */ #ifdef BDE_DEBUGGER #define BDBTRAP(name) \ ss ; \ cmpb $0,_bdb_exists ; \ je 1f ; \ testb $SEL_RPL_MASK,4(%esp) ; \ jne 1f ; \ ss ; \ .globl __CONCAT(__CONCAT(bdb_,name),_ljmp); \ __CONCAT(__CONCAT(bdb_,name),_ljmp): \ ljmp $0,$0 ; \ 1: #else #define BDBTRAP(name) #endif #define BPTTRAP(a) testl $PSL_I,4+8(%esp) ; je 1f ; sti ; 1: ; TRAP(a) MCOUNT_LABEL(user) MCOUNT_LABEL(btrap) IDTVEC(div) pushl $0; TRAP(T_DIVIDE) IDTVEC(dbg) BDBTRAP(dbg) pushl $0; BPTTRAP(T_TRCTRAP) IDTVEC(nmi) pushl $0; TRAP(T_NMI) IDTVEC(bpt) BDBTRAP(bpt) pushl $0; BPTTRAP(T_BPTFLT) IDTVEC(ofl) pushl $0; TRAP(T_OFLOW) IDTVEC(bnd) pushl $0; TRAP(T_BOUND) IDTVEC(ill) pushl $0; TRAP(T_PRIVINFLT) IDTVEC(dna) pushl $0; TRAP(T_DNA) IDTVEC(fpusegm) pushl $0; TRAP(T_FPOPFLT) IDTVEC(tss) TRAP(T_TSSFLT) IDTVEC(missing) TRAP(T_SEGNPFLT) IDTVEC(stk) TRAP(T_STKFLT) IDTVEC(prot) TRAP(T_PROTFLT) IDTVEC(page) TRAP(T_PAGEFLT) IDTVEC(mchk) pushl $0; TRAP(T_MCHK) IDTVEC(rsvd) pushl $0; TRAP(T_RESERVED) IDTVEC(fpu) #if NNPX > 0 /* * Handle like an interrupt (except for accounting) so that we can * call npxintr to clear the error. It would be better to handle * npx interrupts as traps. This used to be difficult for nested * interrupts, but now it is fairly easy - mask nested ones the * same as SWI_AST's. */ pushl $0 /* dummy error code */ pushl $0 /* dummy trap type */ pushal pushl %ds pushl %es /* now stack frame is a trap frame */ movl $KDSEL,%eax movl %ax,%ds movl %ax,%es FAKE_MCOUNT(12*4(%esp)) #ifdef SMP MPLOCKED incl _cnt+V_TRAP FPU_LOCK ECPL_LOCK #ifdef CPL_AND_CML movl _cml,%eax pushl %eax /* save original cml */ orl $SWI_AST_MASK,%eax movl %eax,_cml #else movl _cpl,%eax pushl %eax /* save original cpl */ orl $SWI_AST_MASK,%eax movl %eax,_cpl #endif /* CPL_AND_CML */ ECPL_UNLOCK pushl $0 /* dummy unit to finish intr frame */ #else /* SMP */ movl _cpl,%eax pushl %eax pushl $0 /* dummy unit to finish intr frame */ incl _cnt+V_TRAP orl $SWI_AST_MASK,%eax movl %eax,_cpl #endif /* SMP */ call _npxintr incb _intr_nesting_level MEXITCOUNT jmp _doreti #else /* NNPX > 0 */ pushl $0; TRAP(T_ARITHTRAP) #endif /* NNPX > 0 */ IDTVEC(align) TRAP(T_ALIGNFLT) SUPERALIGN_TEXT .globl _alltraps _alltraps: pushal pushl %ds pushl %es alltraps_with_regs_pushed: movl $KDSEL,%eax movl %ax,%ds movl %ax,%es FAKE_MCOUNT(12*4(%esp)) calltrap: FAKE_MCOUNT(_btrap) /* init "from" _btrap -> calltrap */ MPLOCKED incl _cnt+V_TRAP ALIGN_LOCK ECPL_LOCK #ifdef CPL_AND_CML movl _cml,%eax movl %eax,%ebx /* keep orig. cml here during trap() */ orl $SWI_AST_MASK,%eax movl %eax,_cml #else movl _cpl,%eax movl %eax,%ebx /* keep orig. cpl here during trap() */ orl $SWI_AST_MASK,%eax movl %eax,_cpl #endif ECPL_UNLOCK call _trap /* * Return via _doreti to handle ASTs. Have to change trap frame * to interrupt frame. */ pushl %ebx /* cpl to restore */ subl $4,%esp /* dummy unit to finish intr frame */ MPLOCKED incb _intr_nesting_level MEXITCOUNT jmp _doreti /* * Call gate entry for syscall. * The intersegment call has been set up to specify one dummy parameter. * This leaves a place to put eflags so that the call frame can be * converted to a trap frame. Note that the eflags is (semi-)bogusly * pushed into (what will be) tf_err and then copied later into the * final spot. It has to be done this way because esp can't be just * temporarily altered for the pushfl - an interrupt might come in * and clobber the saved cs/eip. */ SUPERALIGN_TEXT IDTVEC(syscall) pushfl /* save eflags in tf_err for now */ subl $4,%esp /* skip over tf_trapno */ pushal pushl %ds pushl %es movl $KDSEL,%eax /* switch to kernel segments */ movl %ax,%ds movl %ax,%es movl TF_ERR(%esp),%eax /* copy saved eflags to final spot */ movl %eax,TF_EFLAGS(%esp) movl $7,TF_ERR(%esp) /* sizeof "lcall 7,0" */ FAKE_MCOUNT(12*4(%esp)) MPLOCKED incl _cnt+V_SYSCALL SYSCALL_LOCK ECPL_LOCK #ifdef CPL_AND_CML movl $SWI_AST_MASK,_cml #else movl $SWI_AST_MASK,_cpl #endif ECPL_UNLOCK call _syscall /* * Return via _doreti to handle ASTs. */ pushl $0 /* cpl to restore */ subl $4,%esp /* dummy unit to finish intr frame */ movb $1,_intr_nesting_level MEXITCOUNT jmp _doreti /* * Call gate entry for Linux/NetBSD syscall (int 0x80) */ SUPERALIGN_TEXT IDTVEC(int0x80_syscall) subl $8,%esp /* skip over tf_trapno and tf_err */ pushal pushl %ds pushl %es movl $KDSEL,%eax /* switch to kernel segments */ movl %ax,%ds movl %ax,%es movl $2,TF_ERR(%esp) /* sizeof "int 0x80" */ FAKE_MCOUNT(12*4(%esp)) MPLOCKED incl _cnt+V_SYSCALL ALTSYSCALL_LOCK ECPL_LOCK #ifdef CPL_AND_CML movl $SWI_AST_MASK,_cml #else movl $SWI_AST_MASK,_cpl #endif ECPL_UNLOCK call _syscall /* * Return via _doreti to handle ASTs. */ pushl $0 /* cpl to restore */ subl $4,%esp /* dummy unit to finish intr frame */ movb $1,_intr_nesting_level MEXITCOUNT jmp _doreti ENTRY(fork_trampoline) call _spl0 movl _curproc,%eax addl $P_SWITCHTIME,%eax movl _switchtime,%ecx testl %ecx,%ecx jne 1f /* XXX unreachable? */ pushl %eax call _microuptime popl %eax jmp 2f 1: movl %ecx,(%eax) movl _switchtime+4,%edx movl %edx,4(%eax) 2: /* * cpu_set_fork_handler intercepts this function call to * have this call a non-return function to stay in kernel mode. * initproc has its own fork handler, but it does return. */ pushl %ebx /* arg1 */ call %esi /* function */ addl $4,%esp /* cut from syscall */ /* * Return via _doreti to handle ASTs. */ pushl $0 /* cpl to restore */ subl $4,%esp /* dummy unit to finish intr frame */ movb $1,_intr_nesting_level MEXITCOUNT jmp _doreti #ifdef VM86 /* * Include vm86 call routines, which want to call _doreti. */ #include "i386/i386/vm86bios.s" #endif /* VM86 */ /* * Include what was once config+isa-dependent code. * XXX it should be in a stand-alone file. It's still icu-dependent and * belongs in i386/isa. */ #include "i386/isa/vector.s" /* * Include what was once icu-dependent code. * XXX it should be merged into this file (also move the definition of * imen to vector.s or isa.c). * Before including it, set up a normal asm environment so that vector.s * doesn't have to know that stuff is included after it. */ .data ALIGN_DATA .text SUPERALIGN_TEXT #include "i386/isa/ipl.s" --0-2067406009-930333724=:3553 Content-Type: *UNKNOWN*/X-SH Content-ID: Content-Description: /sys/i386/isa/apic_vector.s /* * from: vector.s, 386BSD 0.1 unknown origin * $Id: apic_vector.s,v 1.34 1998/09/06 22:41:41 tegge Exp $ */ #include #include #include "i386/isa/intr_machdep.h" #ifdef FAST_SIMPLELOCK #define GET_FAST_INTR_LOCK \ pushl $_fast_intr_lock ; /* address of lock */ \ call _s_lock ; /* MP-safe */ \ addl $4,%esp #define REL_FAST_INTR_LOCK \ pushl $_fast_intr_lock ; /* address of lock */ \ call _s_unlock ; /* MP-safe */ \ addl $4,%esp #else /* FAST_SIMPLELOCK */ #define GET_FAST_INTR_LOCK \ call _get_isrlock #define REL_FAST_INTR_LOCK \ pushl $_mp_lock ; /* GIANT_LOCK */ \ call _MPrellock ; \ add $4, %esp #endif /* FAST_SIMPLELOCK */ /* convert an absolute IRQ# into a bitmask */ #define IRQ_BIT(irq_num) (1 << (irq_num)) /* make an index into the IO APIC from the IRQ# */ #define REDTBL_IDX(irq_num) (0x10 + ((irq_num) * 2)) /* * Macros for interrupt interrupt entry, call to handler, and exit. */ #ifdef FAST_WITHOUTCPL /* */ #define FAST_INTR(irq_num, vec_name) \ .text ; \ SUPERALIGN_TEXT ; \ IDTVEC(vec_name) ; \ pushl %eax ; /* save only call-used registers */ \ pushl %ecx ; \ pushl %edx ; \ pushl %ds ; \ MAYBE_PUSHL_ES ; \ movl $KDSEL,%eax ; \ movl %ax,%ds ; \ MAYBE_MOVW_AX_ES ; \ FAKE_MCOUNT((4+ACTUALLY_PUSHED)*4(%esp)) ; \ pushl _intr_unit + (irq_num) * 4 ; \ GET_FAST_INTR_LOCK ; \ call *_intr_handler + (irq_num) * 4 ; /* do the work ASAP */ \ REL_FAST_INTR_LOCK ; \ addl $4, %esp ; \ movl $0, lapic_eoi ; \ lock ; \ incl _cnt+V_INTR ; /* book-keeping can wait */ \ movl _intr_countp + (irq_num) * 4, %eax ; \ lock ; \ incl (%eax) ; \ MEXITCOUNT ; \ MAYBE_POPL_ES ; \ popl %ds ; \ popl %edx ; \ popl %ecx ; \ popl %eax ; \ iret #else /* FAST_WITHOUTCPL */ #define FAST_INTR(irq_num, vec_name) \ .text ; \ SUPERALIGN_TEXT ; \ IDTVEC(vec_name) ; \ pushl %eax ; /* save only call-used registers */ \ pushl %ecx ; \ pushl %edx ; \ pushl %ds ; \ MAYBE_PUSHL_ES ; \ movl $KDSEL, %eax ; \ movl %ax, %ds ; \ MAYBE_MOVW_AX_ES ; \ FAKE_MCOUNT((4+ACTUALLY_PUSHED)*4(%esp)) ; \ GET_FAST_INTR_LOCK ; \ pushl _intr_unit + (irq_num) * 4 ; \ call *_intr_handler + (irq_num) * 4 ; /* do the work ASAP */ \ addl $4, %esp ; \ movl $0, lapic_eoi ; \ lock ; \ incl _cnt+V_INTR ; /* book-keeping can wait */ \ movl _intr_countp + (irq_num) * 4,%eax ; \ lock ; \ incl (%eax) ; \ movl _cpl, %eax ; /* unmasking pending HWIs or SWIs? */ \ notl %eax ; \ andl _ipending, %eax ; \ jne 2f ; /* yes, maybe handle them */ \ 1: ; \ MEXITCOUNT ; \ REL_FAST_INTR_LOCK ; \ MAYBE_POPL_ES ; \ popl %ds ; \ popl %edx ; \ popl %ecx ; \ popl %eax ; \ iret ; \ ; \ ALIGN_TEXT ; \ 2: ; \ cmpb $3, _intr_nesting_level ; /* enough stack? */ \ jae 1b ; /* no, return */ \ movl _cpl, %eax ; \ /* XXX next line is probably unnecessary now. */ \ movl $HWI_MASK|SWI_MASK, _cpl ; /* limit nesting ... */ \ lock ; \ incb _intr_nesting_level ; /* ... really limit it ... */ \ sti ; /* to do this as early as possible */ \ MAYBE_POPL_ES ; /* discard most of thin frame ... */ \ popl %ecx ; /* ... original %ds ... */ \ popl %edx ; \ xchgl %eax, 4(%esp) ; /* orig %eax; save cpl */ \ pushal ; /* build fat frame (grrr) ... */ \ pushl %ecx ; /* ... actually %ds ... */ \ pushl %es ; \ movl $KDSEL, %eax ; \ movl %ax, %es ; \ movl (2+8+0)*4(%esp), %ecx ; /* %ecx from thin frame ... */ \ movl %ecx, (2+6)*4(%esp) ; /* ... to fat frame ... */ \ movl (2+8+1)*4(%esp), %eax ; /* ... cpl from thin frame */ \ pushl %eax ; \ subl $4, %esp ; /* junk for unit number */ \ MEXITCOUNT ; \ jmp _doreti #endif /** FAST_WITHOUTCPL */ /* * */ #define PUSH_FRAME \ pushl $0 ; /* dummy error code */ \ pushl $0 ; /* dummy trap type */ \ pushal ; \ pushl %ds ; /* save data and extra segments ... */ \ pushl %es #define POP_FRAME \ popl %es ; \ popl %ds ; \ popal ; \ addl $4+4,%esp #define IOAPICADDR(irq_num) CNAME(int_to_apicintpin) + 16 * (irq_num) + 8 #define REDIRIDX(irq_num) CNAME(int_to_apicintpin) + 16 * (irq_num) + 12 #define MASK_IRQ(irq_num) \ IMASK_LOCK ; /* into critical reg */ \ testl $IRQ_BIT(irq_num), _apic_imen ; \ jne 7f ; /* masked, don't mask */ \ orl $IRQ_BIT(irq_num), _apic_imen ; /* set the mask bit */ \ movl IOAPICADDR(irq_num), %ecx ; /* ioapic addr */ \ movl REDIRIDX(irq_num), %eax ; /* get the index */ \ movl %eax, (%ecx) ; /* write the index */ \ movl IOAPIC_WINDOW(%ecx), %eax ; /* current value */ \ orl $IOART_INTMASK, %eax ; /* set the mask */ \ movl %eax, IOAPIC_WINDOW(%ecx) ; /* new value */ \ 7: ; /* already masked */ \ IMASK_UNLOCK /* * Test to see whether we are handling an edge or level triggered INT. * Level-triggered INTs must still be masked as we don't clear the source, * and the EOI cycle would cause redundant INTs to occur. */ #define MASK_LEVEL_IRQ(irq_num) \ testl $IRQ_BIT(irq_num), _apic_pin_trigger ; \ jz 9f ; /* edge, don't mask */ \ MASK_IRQ(irq_num) ; \ 9: #ifdef APIC_INTR_REORDER #define EOI_IRQ(irq_num) \ movl _apic_isrbit_location + 8 * (irq_num), %eax ; \ movl (%eax), %eax ; \ testl _apic_isrbit_location + 4 + 8 * (irq_num), %eax ; \ jz 9f ; /* not active */ \ movl $0, lapic_eoi ; \ APIC_ITRACE(apic_itrace_eoi, irq_num, APIC_ITRACE_EOI) ; \ 9: #else #define EOI_IRQ(irq_num) \ testl $IRQ_BIT(irq_num), lapic_isr1; \ jz 9f ; /* not active */ \ movl $0, lapic_eoi; \ APIC_ITRACE(apic_itrace_eoi, irq_num, APIC_ITRACE_EOI) ; \ 9: #endif /* * Test to see if the source is currntly masked, clear if so. */ #define UNMASK_IRQ(irq_num) \ IMASK_LOCK ; /* into critical reg */ \ testl $IRQ_BIT(irq_num), _apic_imen ; \ je 7f ; /* bit clear, not masked */ \ andl $~IRQ_BIT(irq_num), _apic_imen ;/* clear mask bit */ \ movl IOAPICADDR(irq_num),%ecx ; /* ioapic addr */ \ movl REDIRIDX(irq_num), %eax ; /* get the index */ \ movl %eax,(%ecx) ; /* write the index */ \ movl IOAPIC_WINDOW(%ecx),%eax ; /* current value */ \ andl $~IOART_INTMASK,%eax ; /* clear the mask */ \ movl %eax,IOAPIC_WINDOW(%ecx) ; /* new value */ \ 7: ; \ IMASK_UNLOCK #ifdef INTR_SIMPLELOCK #define ENLOCK #define DELOCK #define LATELOCK call _get_isrlock #else #define ENLOCK \ ISR_TRYLOCK ; /* XXX this is going away... */ \ testl %eax, %eax ; /* did we get it? */ \ jz 3f #define DELOCK ISR_RELLOCK #define LATELOCK #endif #ifdef APIC_INTR_DIAGNOSTIC #ifdef APIC_INTR_DIAGNOSTIC_IRQ log_intr_event: pushf cli pushl $CNAME(apic_itrace_debuglock) call _s_lock_np addl $4, %esp movl CNAME(apic_itrace_debugbuffer_idx), %ecx andl $32767, %ecx movl _cpuid, %eax shll $8, %eax orl 8(%esp), %eax movw %ax, CNAME(apic_itrace_debugbuffer)(,%ecx,2) incl %ecx andl $32767, %ecx movl %ecx, CNAME(apic_itrace_debugbuffer_idx) pushl $CNAME(apic_itrace_debuglock) call _s_unlock_np addl $4, %esp popf ret #define APIC_ITRACE(name, irq_num, id) \ lock ; /* MP-safe */ \ incl CNAME(name) + (irq_num) * 4 ; \ pushl %eax ; \ pushl %ecx ; \ pushl %edx ; \ movl $(irq_num), %eax ; \ cmpl $APIC_INTR_DIAGNOSTIC_IRQ, %eax ; \ jne 7f ; \ pushl $id ; \ call log_intr_event ; \ addl $4, %esp ; \ 7: ; \ popl %edx ; \ popl %ecx ; \ popl %eax #else #define APIC_ITRACE(name, irq_num, id) \ lock ; /* MP-safe */ \ incl CNAME(name) + (irq_num) * 4 #endif #define APIC_ITRACE_ENTER 1 #define APIC_ITRACE_EOI 2 #define APIC_ITRACE_TRYISRLOCK 3 #define APIC_ITRACE_GOTISRLOCK 4 #define APIC_ITRACE_ENTER2 5 #define APIC_ITRACE_LEAVE 6 #define APIC_ITRACE_UNMASK 7 #define APIC_ITRACE_ACTIVE 8 #define APIC_ITRACE_MASKED 9 #define APIC_ITRACE_NOISRLOCK 10 #define APIC_ITRACE_MASKED2 11 #define APIC_ITRACE_SPLZ 12 #define APIC_ITRACE_DORETI 13 #else #define APIC_ITRACE(name, irq_num, id) #endif #ifdef CPL_AND_CML #define INTR(irq_num, vec_name) \ .text ; \ SUPERALIGN_TEXT ; \ /* _XintrNN: entry point used by IDT/HWIs & splz_unpend via _vec[]. */ \ IDTVEC(vec_name) ; \ PUSH_FRAME ; \ movl $KDSEL, %eax ; /* reload with kernel's data segment */ \ movl %ax, %ds ; \ movl %ax, %es ; \ ; \ APIC_ITRACE(apic_itrace_enter, irq_num, APIC_ITRACE_ENTER) ; \ lock ; /* MP-safe */ \ btsl $(irq_num), iactive ; /* lazy masking */ \ jc 1f ; /* already active */ \ ; \ MASK_LEVEL_IRQ(irq_num) ; \ EOI_IRQ(irq_num) ; \ 0: ; \ APIC_ITRACE(apic_itrace_tryisrlock, irq_num, APIC_ITRACE_TRYISRLOCK) ;\ ENLOCK ; \ ; \ APIC_ITRACE(apic_itrace_gotisrlock, irq_num, APIC_ITRACE_GOTISRLOCK) ;\ AVCPL_LOCK ; /* MP-safe */ \ testl $IRQ_BIT(irq_num), _cpl ; \ jne 2f ; /* this INT masked */ \ testl $IRQ_BIT(irq_num), _cml ; \ jne 2f ; /* this INT masked */ \ orl $IRQ_BIT(irq_num), _cil ; \ AVCPL_UNLOCK ; \ ; \ incb _intr_nesting_level ; \ ; \ /* entry point used by doreti_unpend for HWIs. */ \ __CONCAT(Xresume,irq_num): ; \ FAKE_MCOUNT(12*4(%esp)) ; /* XXX avoid dbl cnt */ \ lock ; incl _cnt+V_INTR ; /* tally interrupts */ \ movl _intr_countp + (irq_num) * 4, %eax ; \ lock ; incl (%eax) ; \ ; \ AVCPL_LOCK ; /* MP-safe */ \ movl _cml, %eax ; \ pushl %eax ; \ orl _intr_mask + (irq_num) * 4, %eax ; \ movl %eax, _cml ; \ AVCPL_UNLOCK ; \ ; \ pushl _intr_unit + (irq_num) * 4 ; \ incl _inside_intr ; \ APIC_ITRACE(apic_itrace_enter2, irq_num, APIC_ITRACE_ENTER2) ; \ sti ; \ call *_intr_handler + (irq_num) * 4 ; \ cli ; \ APIC_ITRACE(apic_itrace_leave, irq_num, APIC_ITRACE_LEAVE) ; \ decl _inside_intr ; \ ; \ lock ; andl $~IRQ_BIT(irq_num), iactive ; \ lock ; andl $~IRQ_BIT(irq_num), _cil ; \ UNMASK_IRQ(irq_num) ; \ APIC_ITRACE(apic_itrace_unmask, irq_num, APIC_ITRACE_UNMASK) ; \ sti ; /* doreti repeats cli/sti */ \ MEXITCOUNT ; \ LATELOCK ; \ jmp _doreti ; \ ; \ ALIGN_TEXT ; \ 1: ; /* active */ \ APIC_ITRACE(apic_itrace_active, irq_num, APIC_ITRACE_ACTIVE) ; \ MASK_IRQ(irq_num) ; \ EOI_IRQ(irq_num) ; \ AVCPL_LOCK ; /* MP-safe */ \ orl $IRQ_BIT(irq_num), _ipending ; \ AVCPL_UNLOCK ; \ lock ; \ btsl $(irq_num), iactive ; /* still active */ \ jnc 0b ; /* retry */ \ POP_FRAME ; \ iret ; \ ; \ ALIGN_TEXT ; \ 2: ; /* masked by cpl|cml */ \ APIC_ITRACE(apic_itrace_masked, irq_num, APIC_ITRACE_MASKED) ; \ orl $IRQ_BIT(irq_num), _ipending ; \ AVCPL_UNLOCK ; \ DELOCK ; /* XXX this is going away... */ \ POP_FRAME ; \ iret ; \ ALIGN_TEXT ; \ 3: ; /* other cpu has isr lock */ \ APIC_ITRACE(apic_itrace_noisrlock, irq_num, APIC_ITRACE_NOISRLOCK) ;\ AVCPL_LOCK ; /* MP-safe */ \ orl $IRQ_BIT(irq_num), _ipending ; \ testl $IRQ_BIT(irq_num), _cpl ; \ jne 4f ; /* this INT masked */ \ testl $IRQ_BIT(irq_num), _cml ; \ jne 4f ; /* this INT masked */ \ orl $IRQ_BIT(irq_num), _cil ; \ AVCPL_UNLOCK ; \ call forward_irq ; /* forward irq to lock holder */ \ POP_FRAME ; /* and return */ \ iret ; \ ALIGN_TEXT ; \ 4: ; /* blocked */ \ APIC_ITRACE(apic_itrace_masked2, irq_num, APIC_ITRACE_MASKED2) ;\ AVCPL_UNLOCK ; \ POP_FRAME ; /* and return */ \ iret #else /* CPL_AND_CML */ #define INTR(irq_num, vec_name) \ .text ; \ SUPERALIGN_TEXT ; \ /* _XintrNN: entry point used by IDT/HWIs & splz_unpend via _vec[]. */ \ IDTVEC(vec_name) ; \ PUSH_FRAME ; \ movl $KDSEL, %eax ; /* reload with kernel's data segment */ \ movl %ax, %ds ; \ movl %ax, %es ; \ ; \ APIC_ITRACE(apic_itrace_enter, irq_num, APIC_ITRACE_ENTER) ; \ lock ; /* MP-safe */ \ btsl $(irq_num), iactive ; /* lazy masking */ \ jc 1f ; /* already active */ \ ; \ MASK_LEVEL_IRQ(irq_num) ; \ EOI_IRQ(irq_num) ; \ 0: ; \ APIC_ITRACE(apic_itrace_tryisrlock, irq_num, APIC_ITRACE_TRYISRLOCK) ;\ ISR_TRYLOCK ; /* XXX this is going away... */ \ testl %eax, %eax ; /* did we get it? */ \ jz 3f ; /* no */ \ ; \ APIC_ITRACE(apic_itrace_gotisrlock, irq_num, APIC_ITRACE_GOTISRLOCK) ;\ AVCPL_LOCK ; /* MP-safe */ \ testl $IRQ_BIT(irq_num), _cpl ; \ jne 2f ; /* this INT masked */ \ AVCPL_UNLOCK ; \ ; \ incb _intr_nesting_level ; \ ; \ /* entry point used by doreti_unpend for HWIs. */ \ __CONCAT(Xresume,irq_num): ; \ FAKE_MCOUNT(12*4(%esp)) ; /* XXX avoid dbl cnt */ \ lock ; incl _cnt+V_INTR ; /* tally interrupts */ \ movl _intr_countp + (irq_num) * 4, %eax ; \ lock ; incl (%eax) ; \ ; \ AVCPL_LOCK ; /* MP-safe */ \ movl _cpl, %eax ; \ pushl %eax ; \ orl _intr_mask + (irq_num) * 4, %eax ; \ movl %eax, _cpl ; \ andl $~IRQ_BIT(irq_num), _ipending ; \ AVCPL_UNLOCK ; \ ; \ pushl _intr_unit + (irq_num) * 4 ; \ APIC_ITRACE(apic_itrace_enter2, irq_num, APIC_ITRACE_ENTER2) ; \ sti ; \ call *_intr_handler + (irq_num) * 4 ; \ cli ; \ APIC_ITRACE(apic_itrace_leave, irq_num, APIC_ITRACE_LEAVE) ; \ ; \ lock ; andl $~IRQ_BIT(irq_num), iactive ; \ UNMASK_IRQ(irq_num) ; \ APIC_ITRACE(apic_itrace_unmask, irq_num, APIC_ITRACE_UNMASK) ; \ sti ; /* doreti repeats cli/sti */ \ MEXITCOUNT ; \ jmp _doreti ; \ ; \ ALIGN_TEXT ; \ 1: ; /* active */ \ APIC_ITRACE(apic_itrace_active, irq_num, APIC_ITRACE_ACTIVE) ; \ MASK_IRQ(irq_num) ; \ EOI_IRQ(irq_num) ; \ AVCPL_LOCK ; /* MP-safe */ \ orl $IRQ_BIT(irq_num), _ipending ; \ AVCPL_UNLOCK ; \ lock ; \ btsl $(irq_num), iactive ; /* still active */ \ jnc 0b ; /* retry */ \ POP_FRAME ; \ iret ; /* XXX: iactive bit might be 0 now */ \ ALIGN_TEXT ; \ 2: ; /* masked by cpl, leave iactive set */ \ APIC_ITRACE(apic_itrace_masked, irq_num, APIC_ITRACE_MASKED) ; \ orl $IRQ_BIT(irq_num), _ipending ; \ AVCPL_UNLOCK ; \ ISR_RELLOCK ; /* XXX this is going away... */ \ POP_FRAME ; \ iret ; \ ALIGN_TEXT ; \ 3: ; /* other cpu has isr lock */ \ APIC_ITRACE(apic_itrace_noisrlock, irq_num, APIC_ITRACE_NOISRLOCK) ;\ AVCPL_LOCK ; /* MP-safe */ \ orl $IRQ_BIT(irq_num), _ipending ; \ testl $IRQ_BIT(irq_num), _cpl ; \ jne 4f ; /* this INT masked */ \ AVCPL_UNLOCK ; \ call forward_irq ; /* forward irq to lock holder */ \ POP_FRAME ; /* and return */ \ iret ; \ ALIGN_TEXT ; \ 4: ; /* blocked */ \ APIC_ITRACE(apic_itrace_masked2, irq_num, APIC_ITRACE_MASKED2) ;\ AVCPL_UNLOCK ; \ POP_FRAME ; /* and return */ \ iret #endif /* CPL_AND_CML */ /* * Handle "spurious INTerrupts". * Notes: * This is different than the "spurious INTerrupt" generated by an * 8259 PIC for missing INTs. See the APIC documentation for details. * This routine should NOT do an 'EOI' cycle. */ .text SUPERALIGN_TEXT .globl _Xspuriousint _Xspuriousint: /* No EOI cycle used here */ iret /* * Handle TLB shootdowns. */ .text SUPERALIGN_TEXT .globl _Xinvltlb _Xinvltlb: pushl %eax #ifdef COUNT_XINVLTLB_HITS ss movl _cpuid, %eax ss incl _xhits(,%eax,4) #endif /* COUNT_XINVLTLB_HITS */ movl %cr3, %eax /* invalidate the TLB */ movl %eax, %cr3 ss /* stack segment, avoid %ds load */ movl $0, lapic_eoi /* End Of Interrupt to APIC */ popl %eax iret #ifdef BETTER_CLOCK /* * Executed by a CPU when it receives an Xcpucheckstate IPI from another CPU, * * - Stores current cpu state in checkstate_cpustate[cpuid] * 0 == user, 1 == sys, 2 == intr * - Stores current process in checkstate_curproc[cpuid] * * - Signals its receipt by setting bit cpuid in checkstate_probed_cpus. * * stack: 0 -> ds, 4 -> ebx, 8 -> eax, 12 -> eip, 16 -> cs, 20 -> eflags */ .text SUPERALIGN_TEXT .globl _Xcpucheckstate .globl _checkstate_cpustate .globl _checkstate_curproc .globl _checkstate_pc _Xcpucheckstate: pushl %eax pushl %ebx pushl %ds /* save current data segment */ movl $KDSEL, %eax movl %ax, %ds /* use KERNEL data segment */ movl $0, lapic_eoi /* End Of Interrupt to APIC */ movl $0, %ebx movl 16(%esp), %eax andl $3, %eax cmpl $3, %eax je 1f #ifdef VM86 testl $PSL_VM, 20(%esp) jne 1f #endif incl %ebx /* system or interrupt */ #ifdef CPL_AND_CML cmpl $0, _inside_intr je 1f incl %ebx /* interrupt */ #endif 1: movl _cpuid, %eax movl %ebx, _checkstate_cpustate(,%eax,4) movl _curproc, %ebx movl %ebx, _checkstate_curproc(,%eax,4) movl 12(%esp), %ebx movl %ebx, _checkstate_pc(,%eax,4) lock /* checkstate_probed_cpus |= (1< Content-Description: /sys/i386/isa/apic_ipl.s /*- * Copyright (c) 1997, by Steve Passe * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. The name of the developer may NOT be used to endorse or promote products * derived from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $Id: apic_ipl.s,v 1.22 1998/09/06 22:41:41 tegge Exp $ */ .data ALIGN_DATA /* current INTerrupt level */ .globl _cil _cil: .long 0 /* current INTerrupt level mask */ .globl _cml _cml: .long 0 /* * Routines used by splz_unpend to build an interrupt frame from a * trap frame. The _vec[] routines build the proper frame on the stack, * then call one of _Xintr0 thru _XintrNN. * * used by: * i386/isa/apic_ipl.s (this file): splz_unpend JUMPs to HWIs. * i386/isa/clock.c: setup _vec[clock] to point at _vec8254. */ .globl _vec _vec: .long vec0, vec1, vec2, vec3, vec4, vec5, vec6, vec7 .long vec8, vec9, vec10, vec11, vec12, vec13, vec14, vec15 .long vec16, vec17, vec18, vec19, vec20, vec21, vec22, vec23 /* * Note: * This is the UP equivilant of _imen. * It is OPAQUE, and must NOT be accessed directly. * It MUST be accessed along with the IO APIC as a 'critical region'. * Accessed by: * INTREN() * INTRDIS() * MAYBE_MASK_IRQ * MAYBE_UNMASK_IRQ * imen_dump() */ .align 2 /* MUST be 32bit aligned */ .globl _apic_imen _apic_imen: .long HWI_MASK /* * */ .text SUPERALIGN_TEXT /* * Interrupt priority mechanism * -- soft splXX masks with group mechanism (cpl) * -- h/w masks for currently active or unused interrupts (imen) * -- ipending = active interrupts currently masked by cpl */ ENTRY(splz) /* * The caller has restored cpl and checked that (ipending & ~cpl) * is nonzero. We have to repeat the check since if there is an * interrupt while we're looking, _doreti processing for the * interrupt will handle all the unmasked pending interrupts * because we restored early. We're repeating the calculation * of (ipending & ~cpl) anyway so that the caller doesn't have * to pass it, so this only costs one "jne". "bsfl %ecx,%ecx" * is undefined when %ecx is 0 so we can't rely on the secondary * btrl tests. */ AICPL_LOCK movl _cpl,%eax #ifdef CPL_AND_CML orl _cml, %eax /* add cml to cpl */ #endif splz_next: /* * We don't need any locking here. (ipending & ~cpl) cannot grow * while we're looking at it - any interrupt will shrink it to 0. */ movl %eax,%ecx notl %ecx /* set bit = unmasked level */ andl _ipending,%ecx /* set bit = unmasked pending INT */ jne splz_unpend AICPL_UNLOCK ret ALIGN_TEXT splz_unpend: bsfl %ecx,%ecx btrl %ecx,_ipending jnc splz_next cmpl $NHWI,%ecx jae splz_swi /* * We would prefer to call the intr handler directly here but that * doesn't work for badly behaved handlers that want the interrupt * frame. Also, there's a problem determining the unit number. * We should change the interface so that the unit number is not * determined at config time. * * The vec[] routines build the proper frame on the stack, * then call one of _Xintr0 thru _XintrNN. */ pushl %ecx AICPL_UNLOCK popl %ecx jmp *_vec(,%ecx,4) ALIGN_TEXT splz_swi: cmpl $SWI_AST,%ecx je splz_next /* "can't happen" */ pushl %eax orl imasks(,%ecx,4),%eax movl %eax,_cpl pushl %ecx AICPL_UNLOCK popl %ecx call *_ihandlers(,%ecx,4) AICPL_LOCK popl %eax movl %eax,_cpl jmp splz_next /* * Fake clock interrupt(s) so that they appear to come from our caller instead * of from here, so that system profiling works. * XXX do this more generally (for all vectors; look up the C entry point). * XXX frame bogusness stops us from just jumping to the C entry point. * We have to clear iactive since this is an unpend call, and it will be * set from the time of the original INT. */ /* * The 'generic' vector stubs. */ #define BUILD_VEC(irq_num) \ ALIGN_TEXT ; \ __CONCAT(vec,irq_num): ; \ popl %eax ; \ pushfl ; \ pushl $KCSEL ; \ pushl %eax ; \ cli ; \ lock ; /* MP-safe */ \ andl $~IRQ_BIT(irq_num), iactive ; /* lazy masking */ \ MEXITCOUNT ; \ APIC_ITRACE(apic_itrace_splz, irq_num, APIC_ITRACE_SPLZ) ; \ jmp __CONCAT(_Xintr,irq_num) BUILD_VEC(0) BUILD_VEC(1) BUILD_VEC(2) BUILD_VEC(3) BUILD_VEC(4) BUILD_VEC(5) BUILD_VEC(6) BUILD_VEC(7) BUILD_VEC(8) BUILD_VEC(9) BUILD_VEC(10) BUILD_VEC(11) BUILD_VEC(12) BUILD_VEC(13) BUILD_VEC(14) BUILD_VEC(15) BUILD_VEC(16) /* 8 additional INTs in IO APIC */ BUILD_VEC(17) BUILD_VEC(18) BUILD_VEC(19) BUILD_VEC(20) BUILD_VEC(21) BUILD_VEC(22) BUILD_VEC(23) /****************************************************************************** * XXX FIXME: figure out where these belong. */ /* this nonsense is to verify that masks ALWAYS have 1 and only 1 bit set */ #define QUALIFY_MASKS_NOT #ifdef QUALIFY_MASKS #define QUALIFY_MASK \ btrl %ecx, %eax ; \ andl %eax, %eax ; \ jz 1f ; \ pushl $bad_mask ; \ call _panic ; \ 1: bad_mask: .asciz "bad mask" #else #define QUALIFY_MASK #endif /* * (soon to be) MP-safe function to clear ONE INT mask bit. * The passed arg is a 32bit u_int MASK. * It sets the associated bit in _apic_imen. * It sets the mask bit of the associated IO APIC register. */ ENTRY(INTREN) pushfl /* save state of EI flag */ cli /* prevent recursion */ IMASK_LOCK /* enter critical reg */ movl 8(%esp), %eax /* mask into %eax */ bsfl %eax, %ecx /* get pin index */ btrl %ecx, _apic_imen /* update _apic_imen */ QUALIFY_MASK shll $4, %ecx movl CNAME(int_to_apicintpin) + 8(%ecx), %edx movl CNAME(int_to_apicintpin) + 12(%ecx), %ecx movl %ecx, (%edx) /* write the target register index */ movl 16(%edx), %eax /* read the target register data */ andl $~IOART_INTMASK, %eax /* clear mask bit */ movl %eax, 16(%edx) /* write the APIC register data */ IMASK_UNLOCK /* exit critical reg */ popfl /* restore old state of EI flag */ ret /* * (soon to be) MP-safe function to set ONE INT mask bit. * The passed arg is a 32bit u_int MASK. * It clears the associated bit in _apic_imen. * It clears the mask bit of the associated IO APIC register. */ ENTRY(INTRDIS) pushfl /* save state of EI flag */ cli /* prevent recursion */ IMASK_LOCK /* enter critical reg */ movl 8(%esp), %eax /* mask into %eax */ bsfl %eax, %ecx /* get pin index */ btsl %ecx, _apic_imen /* update _apic_imen */ QUALIFY_MASK shll $4, %ecx movl CNAME(int_to_apicintpin) + 8(%ecx), %edx movl CNAME(int_to_apicintpin) + 12(%ecx), %ecx movl %ecx, (%edx) /* write the target register index */ movl 16(%edx), %eax /* read the target register data */ orl $IOART_INTMASK, %eax /* set mask bit */ movl %eax, 16(%edx) /* write the APIC register data */ IMASK_UNLOCK /* exit critical reg */ popfl /* restore old state of EI flag */ ret /****************************************************************************** * */ /* * void write_ioapic_mask(int apic, u_int mask); */ #define _INT_MASK 0x00010000 #define _PIN_MASK 0x00ffffff #define _OLD_ESI 0(%esp) #define _OLD_EBX 4(%esp) #define _RETADDR 8(%esp) #define _APIC 12(%esp) #define _MASK 16(%esp) .align 2 write_ioapic_mask: pushl %ebx /* scratch */ pushl %esi /* scratch */ movl _apic_imen, %ebx xorl _MASK, %ebx /* %ebx = _apic_imen ^ mask */ andl $_PIN_MASK, %ebx /* %ebx = _apic_imen & 0x00ffffff */ jz all_done /* no change, return */ movl _APIC, %esi /* APIC # */ movl _ioapic(,%esi,4), %esi /* %esi holds APIC base address */ next_loop: /* %ebx = diffs, %esi = APIC base */ bsfl %ebx, %ecx /* %ecx = index if 1st/next set bit */ jz all_done btrl %ecx, %ebx /* clear this bit in diffs */ leal 16(,%ecx,2), %edx /* calculate register index */ movl %edx, (%esi) /* write the target register index */ movl 16(%esi), %eax /* read the target register data */ btl %ecx, _MASK /* test for mask or unmask */ jnc clear /* bit is clear */ orl $_INT_MASK, %eax /* set mask bit */ jmp write clear: andl $~_INT_MASK, %eax /* clear mask bit */ write: movl %eax, 16(%esi) /* write the APIC register data */ jmp next_loop /* try another pass */ all_done: popl %esi popl %ebx ret #undef _OLD_ESI #undef _OLD_EBX #undef _RETADDR #undef _APIC #undef _MASK #undef _PIN_MASK #undef _INT_MASK #ifdef oldcode _INTREN: movl _apic_imen, %eax notl %eax /* mask = ~mask */ andl _apic_imen, %eax /* %eax = _apic_imen & ~mask */ pushl %eax /* new (future) _apic_imen value */ pushl $0 /* APIC# arg */ call write_ioapic_mask /* modify the APIC registers */ addl $4, %esp /* remove APIC# arg from stack */ popl _apic_imen /* _apic_imen |= mask */ ret _INTRDIS: movl _apic_imen, %eax orl 4(%esp), %eax /* %eax = _apic_imen | mask */ pushl %eax /* new (future) _apic_imen value */ pushl $0 /* APIC# arg */ call write_ioapic_mask /* modify the APIC registers */ addl $4, %esp /* remove APIC# arg from stack */ popl _apic_imen /* _apic_imen |= mask */ ret #endif /* oldcode */ #ifdef ready /* * u_int read_io_apic_mask(int apic); */ ALIGN_TEXT read_io_apic_mask: ret /* * Set INT mask bit for each bit set in 'mask'. * Ignore INT mask bit for all others. * * void set_io_apic_mask(apic, u_int32_t bits); */ ALIGN_TEXT set_io_apic_mask: ret /* * void set_ioapic_maskbit(int apic, int bit); */ ALIGN_TEXT set_ioapic_maskbit: ret /* * Clear INT mask bit for each bit set in 'mask'. * Ignore INT mask bit for all others. * * void clr_io_apic_mask(int apic, u_int32_t bits); */ ALIGN_TEXT clr_io_apic_mask: ret /* * void clr_ioapic_maskbit(int apic, int bit); */ ALIGN_TEXT clr_ioapic_maskbit: ret #endif /** ready */ /****************************************************************************** * */ /* * u_int io_apic_write(int apic, int select); */ ENTRY(io_apic_read) movl 4(%esp), %ecx /* APIC # */ movl _ioapic(,%ecx,4), %edx /* APIC base register address */ movl 8(%esp), %eax /* target register index */ movl %eax, (%edx) /* write the target register index */ movl 16(%edx), %eax /* read the APIC register data */ ret /* %eax = register value */ /* * void io_apic_write(int apic, int select, int value); */ ENTRY(io_apic_write) movl 4(%esp), %ecx /* APIC # */ movl _ioapic(,%ecx,4), %edx /* APIC base register address */ movl 8(%esp), %eax /* target register index */ movl %eax, (%edx) /* write the target register index */ movl 12(%esp), %eax /* target register value */ movl %eax, 16(%edx) /* write the APIC register data */ ret /* %eax = void */ /* * Send an EOI to the local APIC. */ ENTRY(apic_eoi) movl $0, _lapic+0xb0 ret --0-2067406009-930333724=:3553 Content-Type: *UNKNOWN*/X-CSH Content-ID: Content-Description: /sys/i386/isa/ipl_funcs.c /*- * Copyright (c) 1997 Bruce Evans. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $Id: ipl_funcs.c,v 1.13 1998/02/01 22:04:58 bde Exp $ */ #include #include #include #ifndef SMP #if 0 /* * The volatile bitmap variables must be set atomically. This normally * involves using a machine-dependent bit-set or `or' instruction. */ #define DO_SETBITS(name, var, bits) \ void name(void) \ { \ setbits(var, bits); \ } DO_SETBITS(setdelayed, &ipending, loadandclear((unsigned *)&idelayed)) DO_SETBITS(setsoftast, &ipending, SWI_AST_PENDING) DO_SETBITS(setsoftcamnet,&ipending, SWI_CAMNET_PENDING) DO_SETBITS(setsoftcambio,&ipending, SWI_CAMBIO_PENDING) DO_SETBITS(setsoftclock, &ipending, SWI_CLOCK_PENDING) DO_SETBITS(setsoftnet, &ipending, SWI_NET_PENDING) DO_SETBITS(setsofttty, &ipending, SWI_TTY_PENDING) DO_SETBITS(setsoftvm, &ipending, SWI_VM_PENDING) DO_SETBITS(schedsoftcamnet, &idelayed, SWI_CAMNET_PENDING) DO_SETBITS(schedsoftcambio, &idelayed, SWI_CAMBIO_PENDING) DO_SETBITS(schedsoftnet, &idelayed, SWI_NET_PENDING) DO_SETBITS(schedsofttty, &idelayed, SWI_TTY_PENDING) DO_SETBITS(schedsoftvm, &idelayed, SWI_VM_PENDING) unsigned softclockpending(void) { return (ipending & SWI_CLOCK_PENDING); } #define GENSPL(name, set_cpl) \ unsigned name(void) \ { \ unsigned x; \ \ x = cpl; \ set_cpl; \ return (x); \ } GENSPL(splbio, cpl |= bio_imask) GENSPL(splcam, cpl |= cam_imask) GENSPL(splclock, cpl = HWI_MASK | SWI_MASK) GENSPL(splhigh, cpl = HWI_MASK | SWI_MASK) GENSPL(splimp, cpl |= net_imask) GENSPL(splnet, cpl |= SWI_NET_MASK) GENSPL(splsoftcam, cpl |= SWI_CAMBIO_MASK | SWI_CAMNET_MASK) GENSPL(splsoftcambio, cpl |= SWI_CAMBIO_MASK) GENSPL(splsoftcamnet, cpl |= SWI_CAMNET_MASK) GENSPL(splsoftclock, cpl = SWI_CLOCK_MASK) GENSPL(splsofttty, cpl |= SWI_TTY_MASK) GENSPL(splsoftvm, cpl |= SWI_VM_MASK) GENSPL(splstatclock, cpl |= stat_imask) GENSPL(spltty, cpl |= tty_imask) GENSPL(splvm, cpl |= net_imask | bio_imask) #endif void spl0(void) { cpl = SWI_AST_MASK; if (ipending & ~SWI_AST_MASK) splz(); } void splx(unsigned ipl) { cpl = ipl; if (ipending & ~ipl) splz(); } #else /* !SMP */ #include #include #ifndef SPL_DEBUG_POSTCODE #undef POSTCODE #undef POSTCODE_LO #undef POSTCODE_HI #define POSTCODE(X) #define POSTCODE_LO(X) #define POSTCODE_HI(X) #endif /* SPL_DEBUG_POSTCODE */ /* * The volatile bitmap variables must be set atomically. This normally * involves using a machine-dependent bit-set or `or' instruction. */ #define DO_SETBITS(name, var, bits) \ void name(void) \ { \ IFCPL_LOCK(); \ setbits(var, bits); \ IFCPL_UNLOCK(); \ } DO_SETBITS(setdelayed, &ipending, loadandclear((unsigned *)&idelayed)) DO_SETBITS(setsoftast, &ipending, SWI_AST_PENDING) DO_SETBITS(setsoftcamnet,&ipending, SWI_CAMNET_PENDING) DO_SETBITS(setsoftcambio,&ipending, SWI_CAMBIO_PENDING) DO_SETBITS(setsoftclock, &ipending, SWI_CLOCK_PENDING) DO_SETBITS(setsoftnet, &ipending, SWI_NET_PENDING) DO_SETBITS(setsofttty, &ipending, SWI_TTY_PENDING) DO_SETBITS(setsoftvm, &ipending, SWI_VM_PENDING) DO_SETBITS(schedsoftcamnet, &idelayed, SWI_CAMNET_PENDING) DO_SETBITS(schedsoftcambio, &idelayed, SWI_CAMBIO_PENDING) DO_SETBITS(schedsoftnet, &idelayed, SWI_NET_PENDING) DO_SETBITS(schedsofttty, &idelayed, SWI_TTY_PENDING) DO_SETBITS(schedsoftvm, &idelayed, SWI_VM_PENDING) unsigned softclockpending(void) { unsigned x; IFCPL_LOCK(); x = ipending & SWI_CLOCK_PENDING; IFCPL_UNLOCK(); return (x); } /* * This version has to check for bsp_apic_ready, * as calling simple_lock() (ie ss_lock) before then deadlocks the system. * A sample count of GENSPL calls before bsp_apic_ready was set: 2193 */ #ifdef INTR_SPL #ifdef SPL_DEBUG #define MAXZ 100000000 #define SPIN_VAR unsigned z; #define SPIN_RESET z = 0; #if 0 #define SPIN_SPL \ if (++z >= MAXZ) { \ /* XXX allow lock-free panic */ \ bsp_apic_ready = 0; \ panic("\ncil: 0x%08x", cil); \ } #else #define SPIN_SPL \ if (++z >= MAXZ) { \ /* XXX allow lock-free panic */ \ bsp_apic_ready = 0; \ printf("\ncil: 0x%08x", cil); \ breakpoint(); \ } #endif /* 0/1 */ #else /* SPL_DEBUG */ #define SPIN_VAR #define SPIN_RESET #define SPIN_SPL #endif /* SPL_DEBUG */ #endif #ifdef INTR_SPL #define GENSPL(NAME, OP, MODIFIER, PC) \ unsigned NAME(void) \ { \ unsigned x, y; \ SPIN_VAR; \ \ if (!bsp_apic_ready) { \ x = cpl; \ cpl OP MODIFIER; \ return (x); \ } \ \ for (;;) { \ IFCPL_LOCK(); /* MP-safe */ \ x = y = cpl; /* current value */ \ POSTCODE(0x20 | PC); \ if (inside_intr) \ break; /* XXX only 1 INT allowed */ \ y OP MODIFIER; /* desired value */ \ if (cil & y) { /* not now */ \ IFCPL_UNLOCK(); /* allow cil to change */ \ SPIN_RESET; \ while (cil & y) \ SPIN_SPL \ continue; /* try again */ \ } \ break; \ } \ cpl OP MODIFIER; /* make the change */ \ IFCPL_UNLOCK(); \ \ return (x); \ } /* NAME: OP: MODIFIER: PC: */ GENSPL(splbio, |=, bio_imask, 2) GENSPL(splcam, |=, cam_imask, 7) GENSPL(splclock, =, HWI_MASK | SWI_MASK, 3) GENSPL(splhigh, =, HWI_MASK | SWI_MASK, 4) GENSPL(splimp, |=, net_imask, 5) GENSPL(splnet, |=, SWI_NET_MASK, 6) GENSPL(splsoftcam, |=, SWI_CAMBIO_MASK | SWI_CAMNET_MASK, 8) GENSPL(splsoftcambio, |=, SWI_CAMBIO_MASK, 9) GENSPL(splsoftcamnet, |=, SWI_CAMNET_MASK, 10) GENSPL(splsoftclock, =, SWI_CLOCK_MASK, 11) GENSPL(splsofttty, |=, SWI_TTY_MASK, 12) GENSPL(splsoftvm, |=, SWI_VM_MASK, 16) GENSPL(splstatclock, |=, stat_imask, 13) GENSPL(spltty, |=, tty_imask, 14) GENSPL(splvm, |=, net_imask | bio_imask, 15) #else /* INTR_SPL */ #define GENSPL(NAME, set_cpl) \ unsigned NAME(void) \ { \ unsigned x; \ \ if (!bsp_apic_ready) { \ x = cpl; \ set_cpl; \ } \ else { \ IFCPL_LOCK(); \ x = cpl; \ set_cpl; \ IFCPL_UNLOCK(); \ } \ \ return (x); \ } GENSPL(splbio, cpl |= bio_imask) GENSPL(splclock, cpl = HWI_MASK | SWI_MASK) GENSPL(splhigh, cpl = HWI_MASK | SWI_MASK) GENSPL(splimp, cpl |= net_imask) GENSPL(splnet, cpl |= SWI_NET_MASK) GENSPL(splcam, cpl |= cam_imask) GENSPL(splsoftcam, cpl |= SWI_CAMBIO_MASK | SWI_CAMNET_MASK) GENSPL(splsoftcambio, cpl |= SWI_CAMBIO_MASK) GENSPL(splsoftcamnet, cpl |= SWI_CAMNET_MASK) GENSPL(splsoftclock, cpl = SWI_CLOCK_MASK) GENSPL(splsofttty, cpl |= SWI_TTY_MASK) GENSPL(splsoftvm, cpl |= SWI_VM_MASK) GENSPL(splstatclock, cpl |= stat_imask) GENSPL(spltty, cpl |= tty_imask) GENSPL(splvm, cpl |= net_imask | bio_imask) #endif /* INTR_SPL */ void spl0(void) { int unpend; #ifdef INTR_SPL SPIN_VAR; for (;;) { IFCPL_LOCK(); POSTCODE_HI(0xc); if (cil & SWI_AST_MASK) { /* not now */ IFCPL_UNLOCK(); /* allow cil to change */ SPIN_RESET; while (cil & SWI_AST_MASK) SPIN_SPL continue; /* try again */ } break; } #else /* INTR_SPL */ IFCPL_LOCK(); #endif /* INTR_SPL */ cpl = SWI_AST_MASK; unpend = ipending & ~SWI_AST_MASK; IFCPL_UNLOCK(); if (unpend && !inside_intr) splz(); } void splx(unsigned ipl) { int unpend; #ifdef INTR_SPL SPIN_VAR; #endif if (!bsp_apic_ready) { cpl = ipl; if (ipending & ~ipl) splz(); return; } #ifdef INTR_SPL for (;;) { IFCPL_LOCK(); POSTCODE_HI(0xe); if (inside_intr) break; /* XXX only 1 INT allowed */ POSTCODE_HI(0xf); if (cil & ipl) { /* not now */ IFCPL_UNLOCK(); /* allow cil to change */ SPIN_RESET; while (cil & ipl) SPIN_SPL continue; /* try again */ } break; } #else /* INTR_SPL */ IFCPL_LOCK(); #endif /* INTR_SPL */ cpl = ipl; unpend = ipending & ~ipl; IFCPL_UNLOCK(); if (unpend && !inside_intr) splz(); } /* * Replaces UP specific inline found in (?) pci/pci_support.c. * * Stefan said: * You know, that splq() is used in the shared interrupt multiplexer, and that * the SMP version should not have too much overhead. If it is significantly * slower, then moving the splq() out of the loop in intr_mux() and passing in * the logical OR of all mask values might be a better solution than the * current code. (This logical OR could of course be pre-calculated whenever * another shared interrupt is registered ...) */ intrmask_t splq(intrmask_t mask) { intrmask_t tmp, tmp2; #ifdef INTR_SPL for (;;) { IFCPL_LOCK(); tmp = tmp2 = cpl; tmp2 |= mask; if (cil & tmp2) { /* not now */ IFCPL_UNLOCK(); /* allow cil to change */ while (cil & tmp2) /* spin */ ; continue; /* try again */ } break; } cpl = tmp2; #else /* INTR_SPL */ IFCPL_LOCK(); tmp = cpl; cpl |= mask; #endif /* INTR_SPL */ IFCPL_UNLOCK(); return (tmp); } #endif /* !SMP */ --0-2067406009-930333724=:3553-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Jun 25 13:27:57 1999 Delivered-To: freebsd-smp@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 2B4A014DB7 for ; Fri, 25 Jun 1999 13:27:56 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id NAA39178; Fri, 25 Jun 1999 13:27:50 -0700 (PDT) Date: Fri, 25 Jun 1999 13:27:49 -0700 (PDT) From: Julian Elischer To: Alan Cox Cc: Luoqi Chen , dyson@iquest.net, smp@freebsd.org Subject: Re: Call to arms..-SMP In-Reply-To: <19990625135341.H2331@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 So I don't really understand the _cpl stuff. in regards to _cml I guess that theoretically, the BSDI method (lazy treading) makes all that go away doesn't it?. On Fri, 25 Jun 1999, Alan Cox wrote: > On Fri, Jun 25, 1999 at 02:21:08PM -0400, Luoqi Chen wrote: > > > Here's a question: Try compiling a kernel "make -jN". I experienced > > > an immense slow-down. (I added a call to acquire the giant lock if I > > > didn't already hold it just before userret. So doreti needed to release > > > it in all cases anyway.) I concluded that the problem is related > > > to _cpl because the following changes produced the same slowdown: > > > > > > Index: src/sys/i386/i386/exception.s > > > =================================================================== > > > RCS file: /home/ncvs/src/sys/i386/i386/exception.s,v > > > retrieving revision 1.61 > > > diff -c -r1.61 exception.s > > > *** exception.s 1999/06/01 18:19:36 1.61 > > > --- exception.s 1999/06/25 05:54:03 > > > *************** > > > *** 269,275 **** > > > movl $7,TF_ERR(%esp) /* sizeof "lcall 7,0" */ > > > FAKE_MCOUNT(13*4(%esp)) > > > MPLOCKED incl _cnt+V_SYSCALL > > > - SYSCALL_LOCK > > > ECPL_LOCK > > > #ifdef CPL_AND_CML > > > movl $SWI_AST_MASK,_cml > > > --- 269,274 ---- > > > > Maybe not, -current is using the int0x80 syscall interface (altsyscall), > > not the old "lcall 7,0" interface you modified, you might want to remove > > ALTSYSCALL_LOCK and try again. > > > > This fixed the performance problem. I'm amazed that I didn't > deadlock before. > > _cpl still however makes me queasy. Does anyone know why > we're locking a 32-bit store that ought to be atomic > by its very nature? > > Alan > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Jun 25 17:48:36 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 9E6F714D3D for ; Fri, 25 Jun 1999 17:48:24 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: from nonpc.cs.rice.edu (nonpc.cs.rice.edu [128.42.1.219]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id TAA10798; Fri, 25 Jun 1999 19:48:22 -0500 (CDT) Received: (from alc@localhost) by nonpc.cs.rice.edu (8.9.3/8.7.3) id TAA05951; Fri, 25 Jun 1999 19:48:21 -0500 (CDT) Date: Fri, 25 Jun 1999 19:48:21 -0500 From: Alan Cox To: Julian Elischer Cc: Luoqi Chen , dyson@iquest.net, smp@freebsd.org Subject: Re: Call to arms..-SMP Message-ID: <19990625194821.H2974@nonpc.cs.rice.edu> References: <19990625135341.H2331@cs.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Julian Elischer on Fri, Jun 25, 1999 at 01:27:49PM -0700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jun 25, 1999 at 01:27:49PM -0700, Julian Elischer wrote: > > So I don't really understand the _cpl stuff. > in regards to _cml > > I guess that theoretically, the BSDI method (lazy treading) > makes all that go away doesn't it?. > Umm. In general, and not specifically in regard to this problem, the BSDI method is a good idea, but it's not a silver bullet. spl's only exist around data that are shared between the top half of the kernel and (roughly speaking) device-level (bottom-half) code. When you have multiple processors running around the top-half of the kernel, there will be critical sections between those processors that aren't spl'ized. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Jun 26 9:34:17 1999 Delivered-To: freebsd-smp@freebsd.org Received: from henoch.cc.fh-lippe.de (henoch.cc.fh-lippe.de [193.16.112.72]) by hub.freebsd.org (Postfix) with ESMTP id CABBD14FB1; Sat, 26 Jun 1999 09:34:00 -0700 (PDT) (envelope-from lkoeller@cc.fh-lippe.de) Received: from spock.cc.fh-lippe.de([193.16.118.120]) (21463 bytes) by henoch.cc.fh-lippe.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Sat, 26 Jun 1999 18:33:54 +0200 (MET DST) (Smail-3.2.0.101 1997-Dec-17 #3 built 1998-Feb-3) Received: from cc.fh-lippe.de by spock.cc.fh-lippe.de with smtp (Smail3.1.29.1 #2) id m10xvOm-0006yaC; Sat, 26 Jun 99 18:33 MET DST Received: from odie.lippe.de (localhost [127.0.0.1]) by cc.fh-lippe.de (8.9.3/8.9.1) with ESMTP id SAA07021; Sat, 26 Jun 1999 18:32:36 +0200 (CEST) (envelope-from lkoeller@odie.lippe.de) Message-Id: <199906261632.SAA07021@cc.fh-lippe.de> X-Mailer: exmh version 2.0.2 2/24/98 From: Lars =?iso-8859-1?Q?K=F6ller?= Cc: lkoeller@cc.fh-lippe.de To: freebsd-questions@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG, Thierry.Herbelot@alcatel.fr Subject: New freeze with 3.2-RELEASE (SMP and audio)!! In-reply-to: Thierry.Herbelot's message of Thu, 22 Oct 1998 16:15:02 +0200. X-Face: eCcoCV}FjV*O{6>[1$XP/e%]TJhEw2MF33dFh)^HM7Gfd=[/(4+0a$~) id for ; Sat, 26 Jun 1999 23:03:35 +0200 (MET DST) (Smail-3.2.0.101 1997-Dec-17 #3 built 1998-Feb-3) Received: from cc.fh-lippe.de by spock.cc.fh-lippe.de with smtp (Smail3.1.29.1 #2) id m10xzbo-0006yaC; Sat, 26 Jun 99 23:03 MET DST Received: from odie.lippe.de (localhost [127.0.0.1]) by cc.fh-lippe.de (8.9.3/8.9.1) with ESMTP id XAA00889; Sat, 26 Jun 1999 23:03:11 +0200 (CEST) (envelope-from lkoeller@odie.lippe.de) Message-Id: <199906262103.XAA00889@cc.fh-lippe.de> X-Mailer: exmh version 2.0.2 2/24/98 From: Lars =?iso-8859-1?Q?K=F6ller?= To: Lars =?iso-8859-1?Q?K=F6ller?= Cc: freebsd-questions@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG, Thierry.Herbelot@alcatel.fr Subject: Re: New freeze with 3.2-RELEASE (SMP and audio)!! In-reply-to: lkoeller's message of Sat, 26 Jun 1999 18:32:36 +0200. <199906261632.SAA07021@cc.fh-lippe.de> X-Face: eCcoCV}FjV*O{6>[1$XP/e%]TJhEw2MF33dFh)^HM7Gfd=[/(4+0a$~ Hi! > > Sorry for warming this up, but migration from 3.1-R to 3.2-R, from > source was a horor trip! > > However, after having a stable system now, I can tell you the reaseon: > > It was like in 3.0, too (you remember the thread) a problem with the > audio driver under SMP. The soundcard is a Soundblaster AWE 32 (ISA). > > My 3.1-R system was rock solid, with SMP and audio. I use the same > kernel config file for 3.2-R, and here the machine locks up without > any visible reason. After fiddle a littel bit with diferent configs > and different kernel configuration, all leads to the sound driver > (voxware). I also tried the last OSS version, but after loading the > module during install the machine locks up. > > I append my kernel config file, the kernel.config file and the > dmesg output. New since 3.2-R is the output "AWE32 not detected". > > Is there anybody out there with running a SB AWE32 on an 3.2-R > machine with SMP? Regards Lars -- E-Mail: | Lars Koeller Lars.Koeller@Uni-Bielefeld.DE | UNIX Sysadmin lkoeller@cc.fh-lippe.de | Computing Center PGP-key: | University of Bielefeld http://www.nic.surfnet.nl/pgp/pks-toplev.html | Germany ----------- FreeBSD, what else? ---- http://www.freebsd.org ------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message