From owner-freebsd-smp Sun Aug 15 17:16:23 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mail.cybcon.com (mail.cybcon.com [216.190.188.5]) by hub.freebsd.org (Postfix) with ESMTP id E17BA14FBE for ; Sun, 15 Aug 1999 17:16:18 -0700 (PDT) (envelope-from wwoods@cybcon.com) Received: from freebsd.cybcon.com (william@pm3b-42.cybcon.com [205.147.75.107]) by mail.cybcon.com (8.9.0/8.9.0) with ESMTP id RAA04846 for ; Sun, 15 Aug 1999 17:15:30 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 15 Aug 1999 17:15:30 -0700 (PDT) Reply-To: wwoods@cybcon.com From: william woods To: freebsd-smp@freebsd.org Subject: StarOffice on a SMP system.... Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am running StarOffice 5.1 on a Dual PP200 system with 128 megs memory. It runs (can't get the plugins to run), but my main concern is that I find /var/log/messages filled with stuff like this: Aug 15 17:01:35 freebsd /kernel: shared address space fork attempted: pid: 377 Aug 15 17:01:35 freebsd /kernel: shared address space fork attempted: pid: 377 Anybody got any good ideas to fix this? William ---------------------------------- E-Mail: william woods Date: 15-Aug-99 Time: 17:13:36 This message was sent by XFMail ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Aug 16 21: 7:33 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mail.zuhause.org (c2-178.xtlab.com [205.215.217.178]) by hub.freebsd.org (Postfix) with ESMTP id BE668154DA for ; Mon, 16 Aug 1999 21:07:23 -0700 (PDT) (envelope-from bruce@zuhause.mn.org) Received: by mail.zuhause.org (Postfix, from userid 1001) id BCA657C55; Mon, 16 Aug 1999 23:07:48 -0500 (CDT) From: Bruce Albrecht MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14264.57364.624551.180755@celery.zuhause.org> Date: Mon, 16 Aug 1999 23:07:48 -0500 (CDT) To: wwoods@cybcon.com Cc: freebsd-smp@FreeBSD.ORG Subject: Re: StarOffice on a SMP system.... In-Reply-To: References: X-Mailer: VM 6.72 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org william woods writes: > I am running StarOffice 5.1 on a Dual PP200 system with 128 megs memory. It > runs (can't get the plugins to run), but my main concern is that I find > /var/log/messages filled with stuff like this: > > Aug 15 17:01:35 freebsd /kernel: shared address space fork attempted: pid: 377 > Aug 15 17:01:35 freebsd /kernel: shared address space fork attempted: pid: 377 > > Anybody got any good ideas to fix this? Upgrade to -current or downgrade to 3.1R are your only options. 3.2R and -stable do not allow fork when the process has shared memory on an SMP system. There are no plans to backport code that was added to -current to support it to -stable. There was a discussion about this a couple of weeks ago in regards to Wine (which also doesn't work for me on -current, alas). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Aug 16 21:40: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 213D014F99 for ; Mon, 16 Aug 1999 21:40:33 -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 XAA15947; Mon, 16 Aug 1999 23:40:52 -0500 (CDT) Received: (from alc@localhost) by nonpc.cs.rice.edu (8.9.3/8.7.3) id XAA36613; Mon, 16 Aug 1999 23:40:52 -0500 (CDT) Date: Mon, 16 Aug 1999 23:40:52 -0500 From: Alan Cox To: Bruce Albrecht Cc: wwoods@cybcon.com, freebsd-smp@freebsd.org Subject: Re: StarOffice on a SMP system.... Message-ID: <19990816234052.D35833@nonpc.cs.rice.edu> References: <14264.57364.624551.180755@celery.zuhause.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <14264.57364.624551.180755@celery.zuhause.org>; from Bruce Albrecht on Mon, Aug 16, 1999 at 11:07:48PM -0500 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Aug 16, 1999 at 11:07:48PM -0500, Bruce Albrecht wrote: > > Upgrade to -current or downgrade to 3.1R are your only options. Downgrading to 3.1R won't help. It has the same limitation. Sorry, Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 17 5: 9:46 1999 Delivered-To: freebsd-smp@freebsd.org Received: from vexpert.dbai.tuwien.ac.at (vexpert.dbai.tuwien.ac.at [128.130.111.12]) by hub.freebsd.org (Postfix) with ESMTP id D6FD514CD4; Tue, 17 Aug 1999 05:09:32 -0700 (PDT) (envelope-from pfeifer@dbai.tuwien.ac.at) Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id OAA29293; Tue, 17 Aug 1999 14:08:45 +0200 (MET DST) Date: Tue, 17 Aug 1999 14:08:44 +0200 (MET DST) From: Gerald Pfeifer To: Bruce Albrecht Cc: Alan Cox , emulation@freebsd.org, freebsd-smp@freebsd.org Subject: Re: wine and SMP In-Reply-To: <14241.46122.663977.293230@celery.zuhause.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 30 Jul 1999, Bruce Albrecht wrote: > There should be a note added to the wine port to say that it doesn't > work for SMP kernels in 3.2. I guess it's time to start following > -current again. This is very bad. I'm constantly facing the choice of running -STABLE and incomplete Linux and Windows emulation or having to go -CURRENT. In the former case users will complain about the inability to run legacy stuff or stuff where there is not FreeBSD version, in the later case they (probably) will complain about lack of stability. It's bad enough that I have to recompile the kernel to support Wine, but not supporting Wine on current hardware with official releases is really a bad thing[TM]. Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 17 7:52:48 1999 Delivered-To: freebsd-smp@freebsd.org Received: from relay.iunet.it (relay.iunet.it [192.106.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 6107D14C95 for ; Tue, 17 Aug 1999 07:51:55 -0700 (PDT) (envelope-from ccau@itsyn.it) Received: from server1.ecttrieste.com ([151.4.19.2]) by relay.iunet.it (8.9.3/8.9.3) with ESMTP id QAA04180 for ; Tue, 17 Aug 1999 16:51:47 +0200 (MET DST) Received: from 0 ([192.168.10.5]) by server1.ecttrieste.com (Post.Office MTA v3.5.3 release 223 ID# 0-57526U100L2S100V35) with SMTP id com for ; Tue, 17 Aug 1999 16:49:25 +0200 Message-ID: <000f01bee8c0$32e2c5c0$050aa8c0@0> Reply-To: "Corrado Cau" From: "Corrado Cau" To: Subject: -current and SMP Date: Tue, 17 Aug 1999 16:52:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm following with the greatest interest the recent discussions about how to better and make more robust the SMP version of FreeBSD, especially about processor affinity. In my opinion this is a cornerstone of a good SMP implementation. Did some of the fixes make it into the more recent -current snapshots? or we still are at patches level? btw, I found an interesting "how-to" about SMP on linux.com. Ban me from freebsd-* if you wish :-), but there is way too little documentation on SMP around and that article was quite appealing to me. (http://linux.com/howto/Parallel-Processing-HOWTO-1.html) Corrado To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 17 9:17:10 1999 Delivered-To: freebsd-smp@freebsd.org Received: from high-voltage.com (voltage.high-voltage.com [205.243.158.175]) by hub.freebsd.org (Postfix) with SMTP id 707CE1570C for ; Tue, 17 Aug 1999 09:16:59 -0700 (PDT) (envelope-from BMCGROARTY@high-voltage.com) Date: Tue, 17 Aug 1999 11:03 -0600 From: "Brian McGroarty" To: "Corrado Cau" , "freebsd-smp" Subject: RE: -current and SMP Message-ID: <36685390B950D31186D50008C7333C82@high-voltage.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > From: Corrado Cau [mailto:ccau@itsyn.it] > > I'm following with the greatest interest the recent > discussions about how to > better and make more robust the SMP version of FreeBSD, > especially about > processor affinity. In my opinion this is a cornerstone of a good SMP > implementation. > > Did some of the fixes make it into the more recent -current > snapshots? or we > still are at patches level? > > btw, I found an interesting "how-to" about SMP on linux.com. > Ban me from > freebsd-* if you wish :-), but there is way too little > documentation on SMP > around and that article was quite appealing to me. > (http://linux.com/howto/Parallel-Processing-HOWTO-1.html) These may prove useful: * Introduction to Parallel Computing: Design and Analysis of Algorithms * Kumar, Grama, Gupta and Karypis This provides a good overview of the issues you'll need to resolve in parellelization, both hardware and algorithmic. Chapter 4 neatly outlines some of the concerns already expressed in this thread. Of particular interest (to me) is chapter 12: 'Systolic Algorithms and their Mapping onto Parallel Computers.' Maximizing usage of the 'cells' in that chapter provides a good correlation to achieving smooth and uninterrupted audiovisual output. * Parallel Numerical Algorithms * Freeman & Phillips As the title implies, its primary focus is on parallel algorithms. Some of these look very threadable, some are not. After Terry's comment on the desirability of spreading threads for one process across multiple CPUs, I got the idea that it would be interesting to try to detect when this is and isn't beneficial. I'm looking to create a few realistic use cases that cross the spectrum of regularity and granularity of MESI shared memory faults. * Unix Systems for Modern Architectures: Symmetric Multiprocesssing and Caching for Kernel Programmers I've got this on order from Amazon.com - I'll drop a note when I've given that a first review. I plan on developing my next game title under FreeBSD, although Windows and Playstation 2 are the target platforms. Hopefully I'll be able to sell the company on publishing Linux and FreeBSD versions of the title on the Windows disc. I can use FreeBSD's SMP support for better performance of our prototype code and once I've better learned FreeBSD (I'm working through McKusick's kernel tapes as I can afford them) I want to work on real time thread scheduling extensions and overall SMP scheduling efficiency if nobody else has tackled them first. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Aug 17 22:15:41 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mail.zuhause.org (c2-178.xtlab.com [205.215.217.178]) by hub.freebsd.org (Postfix) with ESMTP id 9FA5614DC4; Tue, 17 Aug 1999 22:15:27 -0700 (PDT) (envelope-from bruce@zuhause.mn.org) Received: by mail.zuhause.org (Postfix, from userid 1001) id 207207C56; Wed, 18 Aug 1999 00:16:00 -0500 (CDT) From: Bruce Albrecht MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14266.16783.981472.623589@celery.zuhause.org> Date: Wed, 18 Aug 1999 00:15:59 -0500 (CDT) To: Henry Miller Cc: emulation@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: wine and SMP In-Reply-To: References: X-Mailer: VM 6.72 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Henry Miller writes: > > It's bad enough that I have to recompile the kernel to support Wine, but > > not supporting Wine on current hardware with official releases is really > > a bad thing[TM]. > > Very bad. Make it a configureable option if it isn't stable enough to > general use, wine users have to compile kernels anyway, so we can do this. The problem is that there were changes put in place back in March (I think) that fixed a number of problems, but as part of the fix, had to disable fork with shared memory for SMP. This was later fixed in current, but the developer who fixed it never wrote a back-port to -stable. Like all volunteer projects, if you're willing to track this down, back-port and test it, it will probably get added to -stable if you can get a champion among the committers to work with you on it (at least for testing). Even though SMP is supported in -stable, you must recognize that it's a fairly weak implementation. For the most part, there's only one kernel lock, so in general, you can't have more than one CPU doing kernel stuff, even though the two kernel requests (for example, two separate disk controllers, or two NICs) are independent of each other. There's no processor affinity. A threaded process can't have multiple threads running simultaneously on multiple CPUs. I'm sure there are other deficiencies I've left out. > Point is, I can do that, but since I'm not a devolper it is against the > spirit of -current for me to do so. (not to mention I then have to > figgure out how to upgrade from -stable to -current) This is only partly true. You don't have to rebuild -current on a daily basis, you could just pick a -current snap, install it, and not upgrade until you're comfortable with upgrading again. It's not recommended to run -current on a production machine, but chances are, if you're running Wine, it's not a production machine. If you have problems with -current, you're expected to know enough to be able to provide a coherent description of the problem, and be able to get traces and/or dumps. If you pick a snapshot at a time where there's not a lot of new code being added, chances are you'll not have any problems. I'm running -current from about July 30th, and I've not encountered any problems with the system. I'm also having problems with Wine, but I haven't taken the time to track it down, or even if it's SMP related. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 18 4:37:31 1999 Delivered-To: freebsd-smp@freebsd.org Received: from picalon.gun.de (picalon.gun.de [194.77.0.18]) by hub.freebsd.org (Postfix) with ESMTP id D5C5A14D66 for ; Wed, 18 Aug 1999 04:37:23 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: from klemm.gtn.com (pppak04.gtn.com [194.231.123.169]) by picalon.gun.de (8.9.3/8.9.3) with ESMTP id NAA15402; Wed, 18 Aug 1999 13:37:54 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.9.3/8.9.3) id NAA56143; Wed, 18 Aug 1999 13:18:07 +0200 (CEST) (envelope-from andreas) Date: Wed, 18 Aug 1999 13:18:03 +0200 From: Andreas Klemm To: william woods Cc: freebsd-smp@FreeBSD.ORG Subject: Re: StarOffice on a SMP system.... Message-ID: <19990818131802.A40210@titan.klemm.gtn.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from william woods on Sun, Aug 15, 1999 at 05:15:30PM -0700 X-Operating-System: FreeBSD 3.2-STABLE SMP X-Disclaimer: A free society is one where it is safe to be unpopular Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Aug 15, 1999 at 05:15:30PM -0700, william woods wrote: > I am running StarOffice 5.1 on a Dual PP200 system with 128 megs memory. It > runs (can't get the plugins to run), but my main concern is that I find > /var/log/messages filled with stuff like this: > > Aug 15 17:01:35 freebsd /kernel: shared address space fork attempted: pid: 377 > Aug 15 17:01:35 freebsd /kernel: shared address space fork attempted: pid: 377 I'm running FreeBSD-3.2-STABLE (last build around a week ago). There I got the error message using a SMP kernel, that linux_clone() isn't SMP ready. BTW, when running Staroffice after installation in my local account /home/andreas/Office51, staroffice every time tries to run setup again :-/ I tried now both installation options, workstation and full install with the same result. Could it be related to the fact, that I installed staroffice rpm package to the path /home/staroffice ? rpm -i --ignoreos --root /home/staroffice --dbpath /var/lib/rpm --nodeps --replacepkgs --noscripts forgotthenameofthepackage.rpm O.k. this doesn't belong here, but if you have an Idea, what's causing this, then it would be nice, if you could drop some mail to me. Andreas /// -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Latest song from our band: http://www.freebsd.org/~andreas/mp3/schaukel.mp3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 18 11:21:38 1999 Delivered-To: freebsd-smp@freebsd.org Received: from houston.matchlogic.com (houston.matchlogic.com [205.216.147.127]) by hub.freebsd.org (Postfix) with ESMTP id A3CA5151BA for ; Wed, 18 Aug 1999 11:21:15 -0700 (PDT) (envelope-from crandall@matchlogic.com) Received: by houston.matchlogic.com with Internet Mail Service (5.5.2448.0) id ; Wed, 18 Aug 1999 12:21:04 -0600 Message-ID: <64003B21ECCAD11185C500805F31EC0303786DA1@houston.matchlogic.com> From: Charles Randall To: freebsd-smp@FreeBSD.ORG Subject: SMP differences between -stable and -current (RE: wine and SMP) Date: Wed, 18 Aug 1999 12:21:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Note: only to -smp] Which of those limitations also apply to -current? Charles -----Original Message----- From: Bruce Albrecht [mailto:bruce@zuhause.mn.org] ... Even though SMP is supported in -stable, you must recognize that it's a fairly weak implementation. For the most part, there's only one kernel lock, so in general, you can't have more than one CPU doing kernel stuff, even though the two kernel requests (for example, two separate disk controllers, or two NICs) are independent of each other. There's no processor affinity. A threaded process can't have multiple threads running simultaneously on multiple CPUs. I'm sure there are other deficiencies I've left out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 18 15:32:12 1999 Delivered-To: freebsd-smp@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id EB79E14F1F for ; Wed, 18 Aug 1999 15:32:06 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id AAA09707 for freebsd-smp@FreeBSD.ORG; Thu, 19 Aug 1999 00:32:55 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 732E388AB; Thu, 19 Aug 1999 00:28:02 +0200 (CEST) Date: Thu, 19 Aug 1999 00:28:02 +0200 From: Ollivier Robert To: freebsd-smp@FreeBSD.ORG Subject: Re: StarOffice on a SMP system.... Message-ID: <19990819002802.A87509@keltia.freenix.fr> Mail-Followup-To: freebsd-smp@FreeBSD.ORG References: <19990818131802.A40210@titan.klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: <19990818131802.A40210@titan.klemm.gtn.com>; from Andreas Klemm on Wed, Aug 18, 1999 at 01:18:03PM +0200 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5543 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Andreas Klemm: > O.k. this doesn't belong here, but if you have an Idea, what's > causing this, then it would be nice, if you could drop some > mail to me. You MUST have this patch applied. Marcel will probably commit before the end of the week. Index: procfs_status.c =================================================================== RCS file: /repository/src/sys/miscfs/procfs/procfs_status.c,v retrieving revision 1.12 diff -c -r1.12 procfs_status.c *** procfs_status.c 1999/01/05 03:53:06 1.12 --- procfs_status.c 1999/05/15 20:36:16 *************** *** 47,52 **** --- 47,56 ---- #include #include #include + #include + #include + #include + #include int procfs_dostatus(curp, p, pfs, uio) *************** *** 164,178 **** return (EOPNOTSUPP); /* ! * For now, this is a hack. To implement this fully would require ! * groping around in the process address space to follow argv etc. */ ! ps = psbuf; ! bcopy(p->p_comm, ps, MAXCOMLEN); ! ps[MAXCOMLEN] = '\0'; ! ps += strlen(ps); ! ! ps += sprintf(ps, "\n"); xlen = ps - psbuf; xlen -= uio->uio_offset; --- 168,207 ---- return (EOPNOTSUPP); /* ! * This is a hack: the correct behaviour is only implemented for ! * the case of the current process enquiring about its own argv ! * (due to the difficulty of accessing other processes' address space). ! * For other cases, we cop out and just return argv[0] from p->p_comm. ! * Note that if the argv is no longer available, we deliberately ! * don't fall back on p->p_comm or return an error: the authentic ! * Linux behaviour is to return zero-length in this case. */ ! if (curproc == p) { ! struct ps_strings pstr; ! int i; ! size_t bytes_left, done; ! ! error = copyin((void*)PS_STRINGS, &pstr, sizeof(pstr)); ! if (error) return (error); ! bytes_left = sizeof(psbuf); ! ps = psbuf; ! for (i = 0; bytes_left && (i < pstr.ps_nargvstr); i++) { ! error = copyinstr(pstr.ps_argvstr[i], ps, ! bytes_left, &done); ! /* If too long or malformed, just truncate */ ! if (error) { ! error = 0; ! break; ! } ! ps += done; ! bytes_left -= done; ! } ! } else { ! ps = psbuf; ! bcopy(p->p_comm, ps, MAXCOMLEN); ! ps[MAXCOMLEN] = '\0'; ! ps += strlen(ps); ! } xlen = ps - psbuf; xlen -= uio->uio_offset; -- Sascha Blank | FreeBSD - Student and System Administrator | that's where you want to go today! at the University of Trier, Germany | mailto:blank@fox.uni-trier.de | See http://www.freebsd.org for details -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Aug 18 15:57:11 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mail.cybcon.com (mail.cybcon.com [216.190.188.5]) by hub.freebsd.org (Postfix) with ESMTP id CB1CA14EA3 for ; Wed, 18 Aug 1999 15:57:08 -0700 (PDT) (envelope-from wwoods@cybcon.com) Received: from freebsd.cybcon.com (william@pm3a-28.cybcon.com [205.147.75.157]) by mail.cybcon.com (8.9.0/8.9.0) with ESMTP id PAA28383; Wed, 18 Aug 1999 15:54:51 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19990819002802.A87509@keltia.freenix.fr> Date: Wed, 18 Aug 1999 15:55:14 -0700 (PDT) Reply-To: wwoods@cybcon.com From: william woods To: Ollivier Robert Subject: Re: StarOffice on a SMP system.... Cc: freebsd-smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What does this patch do and how would I apply it? On 18-Aug-99 Ollivier Robert wrote: > According to Andreas Klemm: >> O.k. this doesn't belong here, but if you have an Idea, what's >> causing this, then it would be nice, if you could drop some >> mail to me. > > You MUST have this patch applied. Marcel will probably commit before the end > of the week. > > Index: procfs_status.c > =================================================================== > RCS file: /repository/src/sys/miscfs/procfs/procfs_status.c,v > retrieving revision 1.12 > diff -c -r1.12 procfs_status.c > *** procfs_status.c 1999/01/05 03:53:06 1.12 > --- procfs_status.c 1999/05/15 20:36:16 > *************** > *** 47,52 **** > --- 47,56 ---- > #include > #include > #include > + #include > + #include > + #include > + #include > > int > procfs_dostatus(curp, p, pfs, uio) > *************** > *** 164,178 **** > return (EOPNOTSUPP); > > /* > ! * For now, this is a hack. To implement this fully would require > ! * groping around in the process address space to follow argv etc. > */ > ! ps = psbuf; > ! bcopy(p->p_comm, ps, MAXCOMLEN); > ! ps[MAXCOMLEN] = '\0'; > ! ps += strlen(ps); > ! > ! ps += sprintf(ps, "\n"); > > xlen = ps - psbuf; > xlen -= uio->uio_offset; > --- 168,207 ---- > return (EOPNOTSUPP); > > /* > ! * This is a hack: the correct behaviour is only implemented for > ! * the case of the current process enquiring about its own argv > ! * (due to the difficulty of accessing other processes' address space). > ! * For other cases, we cop out and just return argv[0] from p->p_comm. > ! * Note that if the argv is no longer available, we deliberately > ! * don't fall back on p->p_comm or return an error: the authentic > ! * Linux behaviour is to return zero-length in this case. > */ > ! if (curproc == p) { > ! struct ps_strings pstr; > ! int i; > ! size_t bytes_left, done; > ! > ! error = copyin((void*)PS_STRINGS, &pstr, sizeof(pstr)); > ! if (error) return (error); > ! bytes_left = sizeof(psbuf); > ! ps = psbuf; > ! for (i = 0; bytes_left && (i < pstr.ps_nargvstr); i++) { > ! error = copyinstr(pstr.ps_argvstr[i], ps, > ! bytes_left, &done); > ! /* If too long or malformed, just truncate */ > ! if (error) { > ! error = 0; > ! break; > ! } > ! ps += done; > ! bytes_left -= done; > ! } > ! } else { > ! ps = psbuf; > ! bcopy(p->p_comm, ps, MAXCOMLEN); > ! ps[MAXCOMLEN] = '\0'; > ! ps += strlen(ps); > ! } > > xlen = ps - psbuf; > xlen -= uio->uio_offset; > > -- > Sascha Blank | FreeBSD - > Student and System Administrator | that's where you want to go today! > at the University of Trier, Germany | > mailto:blank@fox.uni-trier.de | See http://www.freebsd.org for details > > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- > roberto@keltia.freenix.fr > FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message ---------------------------------- E-Mail: william woods Date: 18-Aug-99 Time: 15:53:49 This message was sent by XFMail ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Aug 19 5:31: 4 1999 Delivered-To: freebsd-smp@freebsd.org Received: from probe.gent.online.be (probe.gent.online.be [194.88.114.13]) by hub.freebsd.org (Postfix) with ESMTP id AD09F15128 for ; Thu, 19 Aug 1999 05:31:00 -0700 (PDT) (envelope-from freebsd-smp@probe.gent.online.be) Received: (from root@localhost) by probe.gent.online.be (8.9.1/8.9.1) id OAA23288 for freebsd-smp@freebsd.org; Thu, 19 Aug 1999 14:27:14 +0200 Date: Thu, 19 Aug 1999 14:27:14 +0200 From: freebsd-smp@probe.gent.online.be Message-Id: <199908191227.OAA23288@probe.gent.online.be> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org subscribe freebsd-smp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Aug 19 10: 9:39 1999 Delivered-To: freebsd-smp@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 1BB6614E52 for ; Thu, 19 Aug 1999 10:09:34 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id TAA26160 for freebsd-smp@FreeBSD.ORG; Thu, 19 Aug 1999 19:09:39 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id D19208795; Thu, 19 Aug 1999 08:04:41 +0200 (CEST) Date: Thu, 19 Aug 1999 08:04:41 +0200 From: Ollivier Robert To: freebsd-smp@FreeBSD.ORG Subject: Re: StarOffice on a SMP system.... Message-ID: <19990819080441.A90760@keltia.freenix.fr> Mail-Followup-To: freebsd-smp@FreeBSD.ORG References: <19990819002802.A87509@keltia.freenix.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: ; from william woods on Wed, Aug 18, 1999 at 03:55:14PM -0700 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5543 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to william woods: > What does this patch do and how would I apply it? Did you read the patch ? It enables Linux programs to pickup up the parameters on the command-line. Without it, soffice.bin doesn't see any argument and run the setup.bin binary instead. cd /sys/miscfs/procfs patch ; Thu, 19 Aug 1999 13:12:43 -0700 (PDT) (envelope-from freebsd-smp@scc.nl) Received: from mail.scc.nl (i230.ztm.euronet.nl [194.134.67.31]) by gaia.euronet.nl (8.8.8/8.8.8) with ESMTP id WAA02295 from for ; Thu, 19 Aug 1999 22:11:58 +0200 (MET DST) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id WAA13390 for smp@FreeBSD.ORG; Thu, 19 Aug 1999 22:11:06 +0200 (CEST) (envelope-from freebsd-smp@scc.nl) Received: from GATEWAY by scones.sup.scc.nl with netnews for smp@FreeBSD.ORG (smp@FreeBSD.ORG) To: smp@FreeBSD.ORG Date: Thu, 19 Aug 1999 22:11:03 +0200 From: Marcel Moolenaar Message-ID: <37BC64D7.E3498E27@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <19990819002802.A87509@keltia.freenix.fr>, <19990819080441.A90760@keltia.freenix.fr> Subject: Re: StarOffice on a SMP system.... Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ollivier Robert wrote: > Did you read the patch ? It enables Linux programs to pickup up the parameters > on the command-line. Without it, soffice.bin doesn't see any argument and run > the setup.bin binary instead. > > cd /sys/miscfs/procfs > patch ; Thu, 19 Aug 1999 17:40:42 -0700 (PDT) (envelope-from bruce@zuhause.mn.org) Received: by mail.zuhause.org (Postfix, from userid 1001) id 5171C7C55; Thu, 19 Aug 1999 19:39:35 -0500 (CDT) From: Bruce Albrecht MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14268.41927.8972.298219@celery.zuhause.org> Date: Thu, 19 Aug 1999 19:39:35 -0500 (CDT) To: freebsd-smp@FreeBSD.ORG Subject: Re: SMP differences between -stable and -current (RE: wine and SMP) In-Reply-To: <64003B21ECCAD11185C500805F31EC0303786DA1@houston.matchlogic.com> References: <64003B21ECCAD11185C500805F31EC0303786DA1@houston.matchlogic.com> X-Mailer: VM 6.72 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I could be wrong, but I think all of them apply. I think there were a few things that were moved out of the Big Kernel Lock, and some people have been playing around with processor affinity lately. However, when these things are fixed in -current (I believe fixing these things are all goals for 4.0), they probably won't be back-ported to -stable. Charles Randall writes: > Which of those limitations also apply to -current? > > -----Original Message----- > From: Bruce Albrecht [mailto:bruce@zuhause.mn.org] > ... > Even though SMP is supported in -stable, you must recognize that it's > a fairly weak implementation. For the most part, there's only one > kernel lock, so in general, you can't have more than one CPU doing > kernel stuff, even though the two kernel requests (for example, two > separate disk controllers, or two NICs) are independent of each other. > There's no processor affinity. A threaded process can't have multiple > threads running simultaneously on multiple CPUs. I'm sure there are > other deficiencies I've left out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Aug 20 14:18:38 1999 Delivered-To: freebsd-smp@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id AD5AC15B45 for ; Fri, 20 Aug 1999 14:18:04 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id RAA16594; Fri, 20 Aug 1999 17:17:22 -0400 (EDT) (envelope-from luoqi) Date: Fri, 20 Aug 1999 17:17:22 -0400 (EDT) From: Luoqi Chen Message-Id: <199908202117.RAA16594@lor.watermarkgroup.com> To: bruce@zuhause.mn.org, freebsd-smp@FreeBSD.ORG Subject: Re: SMP differences between -stable and -current (RE: wine and SMP) Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I could be wrong, but I think all of them apply. I think there were a > few things that were moved out of the Big Kernel Lock, and some people > have been playing around with processor affinity lately. However, > when these things are fixed in -current (I believe fixing these things > are all goals for 4.0), they probably won't be back-ported to -stable. > > Charles Randall writes: > > Which of those limitations also apply to -current? > > > > -----Original Message----- > > From: Bruce Albrecht [mailto:bruce@zuhause.mn.org] > > ... > > Even though SMP is supported in -stable, you must recognize that it's > > a fairly weak implementation. For the most part, there's only one > > kernel lock, so in general, you can't have more than one CPU doing > > kernel stuff, even though the two kernel requests (for example, two > > separate disk controllers, or two NICs) are independent of each other. > > There's no processor affinity. A threaded process can't have multiple > > threads running simultaneously on multiple CPUs. I'm sure there are > > other deficiencies I've left out. > A threaded process *can* have multiple threads simultaneously on multiple CPUs in -current, and I'm getting close on moving interrupt handling out of GKL, that is, allowing multiple interrupts be serviced simultaneously. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Aug 20 14:26:24 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 665FD14EE5 for ; Fri, 20 Aug 1999 14:26:21 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id OAA22361; Fri, 20 Aug 1999 14:25:04 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpdAAA2LayKR; Fri Aug 20 14:24:52 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id OAA14055; Fri, 20 Aug 1999 14:25:04 -0700 (MST) From: Terry Lambert Message-Id: <199908202125.OAA14055@usr09.primenet.com> Subject: Re: SMP differences between -stable and -current (RE: wine and SMP) To: luoqi@watermarkgroup.com (Luoqi Chen) Date: Fri, 20 Aug 1999 21:25:04 +0000 (GMT) Cc: bruce@zuhause.mn.org, freebsd-smp@FreeBSD.ORG In-Reply-To: <199908202117.RAA16594@lor.watermarkgroup.com> from "Luoqi Chen" at Aug 20, 99 05:17:22 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 > A threaded process *can* have multiple threads simultaneously on > multiple CPUs in -current, By this, you mean a _kernel_ threaded process, not a libc_r and libpthreads threaded process, right? > and I'm getting close on moving interrupt handling out of GKL, > that is, allowing multiple interrupts be serviced simultaneously. Go Loqui, go! 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 Aug 20 14:28:17 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 062A915A28 for ; Fri, 20 Aug 1999 14:28:15 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id OAA10509; Fri, 20 Aug 1999 14:25:57 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp02.primenet.com, id smtpd010400; Fri Aug 20 14:25:49 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id OAA14077; Fri, 20 Aug 1999 14:25:45 -0700 (MST) From: Terry Lambert Message-Id: <199908202125.OAA14077@usr09.primenet.com> Subject: Re: SMP differences between -stable and -current (RE: wine and SMP) To: luoqi@watermarkgroup.com (Luoqi Chen) Date: Fri, 20 Aug 1999 21:25:45 +0000 (GMT) Cc: bruce@zuhause.mn.org, freebsd-smp@FreeBSD.ORG In-Reply-To: <199908202117.RAA16594@lor.watermarkgroup.com> from "Luoqi Chen" at Aug 20, 99 05:17:22 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 > I'm getting close on moving interrupt handling out of GKL, > that is, allowing multiple interrupts be serviced simultaneously. Sorry for the typo... Go, Luoqi, go! 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 Aug 20 15:10:38 1999 Delivered-To: freebsd-smp@freebsd.org Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30]) by hub.freebsd.org (Postfix) with ESMTP id 31AE714D8D for ; Fri, 20 Aug 1999 15:10:33 -0700 (PDT) (envelope-from blanquer@cs.ucsb.edu) Received: from ella (ella [128.111.49.42]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id PAA18678; Fri, 20 Aug 1999 15:09:39 -0700 (PDT) Date: Fri, 20 Aug 1999 15:09:38 -0700 (PDT) From: "Josep Maria M. Blanquer" X-Sender: blanquer@ella To: Luoqi Chen Cc: freebsd-smp@FreeBSD.ORG Subject: Re: SMP differences between -stable and -current (RE: wine and SMP) 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 > A threaded process *can* have multiple threads simultaneously on >multiple CPUs in -current, and I'm getting close on moving interrupt >handling out of GKL, that is, allowing multiple interrupts be serviced >simultaneously. Hmmm, that sounds pretty interesting! Do you have any docs explaining this? I mean the way you are implementing it...The docs I've seen are usually explaining possible strategies and problems, but it's difficult to know the actual status of it. Of course one can always take a look to the kernel code, but it's not easy task, specially because the SMP code it's kinda sparse... With some docs about the actual implementation would be much more easy for others to start playing with things like proc. affinity and many other performance improvements... BTW is that code going to be part of -current? if so, do you know when (aprox)? Nice, that should really make a difference in for example server boxes with a lot of traffic... Josep M. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Aug 21 7:24: 4 1999 Delivered-To: freebsd-smp@freebsd.org Received: from db.geocrawler.com (db.gotocity.com [165.90.140.10]) by hub.freebsd.org (Postfix) with ESMTP id 7B29E150C1 for ; Sat, 21 Aug 1999 07:24:01 -0700 (PDT) (envelope-from nobody@db.geocrawler.com) Received: (from nobody@localhost) by db.geocrawler.com (8.8.8/8.8.8) id JAA17618; Sat, 21 Aug 1999 09:20:42 -0500 Date: Sat, 21 Aug 1999 09:20:42 -0500 Message-Id: <199908211420.JAA17618@db.geocrawler.com> To: freebsd-smp@freebsd.org Subject: SMP poor? From: "Geocrawler.com" Reply-To: "Martin Dvorak" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message was sent from Geocrawler.com by "Martin Dvorak" Be sure to reply to that address. Hi all, I've got a question regarding performance of SMP FreeBSD system. I've got an Intel N440BX machine with two 400Mhz Pentium II processors and dual Symbios SCSI controller (53C876) running FreeBSD 3.2-RELEASE. The machine is serving as an Internet server (not workstation). I had RedHat installed on this machine, but because of machine purpose, stability and inclination to FreeBSD, I recently moved to FreeBSD. Immediately after the installation of FreeBSD I noticed that the system is much more slower than it was with RedHat. So I tried to optimize the kernel, I tried to play with different configuration parameters etc. but nothing... While on RedHat I was copying large files in speed around 20MB/sec, now I am glad if I get to 5MB/sec. Also, untarring 1.5 MB file takes about 40sec which is not what anyone could expect mentioned hardware. Is there something I could do to speed up the system? I can send my kernel config file if anyone is so kind to give me some advice. Or is it because of slow SMP implementation in FreeBSD? Or are the SCSI drivers for SymBIOS 53C876 controller so much slower the RedHats' (I tried it with or without CAM, both were the same). Thanks very much for any advice or opinion. Martin Geocrawler.com - The Knowledge Archive To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Aug 21 11:15: 5 1999 Delivered-To: freebsd-smp@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id F2E44154A7; Sat, 21 Aug 1999 11:14:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A1BBC1CD8B9; Sat, 21 Aug 1999 11:14:56 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Sat, 21 Aug 1999 11:14:55 -0700 (PDT) From: Kris Kennaway To: Martin Dvorak Cc: freebsd-smp@freebsd.org Subject: Re: SMP poor? In-Reply-To: <199908211420.JAA17618@db.geocrawler.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 Sat, 21 Aug 1999, Geocrawler.com wrote: > Immediately after the installation of FreeBSD I noticed that the > system is much more slower than it was with RedHat. So I tried to > optimize the kernel, I tried to play with different configuration > parameters etc. but nothing... While on RedHat I was copying large > files in speed around 20MB/sec, now I am glad if I get to 5MB/sec. > Also, untarring 1.5 MB file takes about 40sec which is not what anyone > could expect mentioned hardware. Linux systems usually mount filesystems "async" by default, which is very dangerous if the system crashes. FreeBSD defaults to something slower, but safer - but you can mount your volumes async if you really want to. Also look at SoftUpdates which provides near-async speeds but without the danger factor. Check the mailing-lists for more info - it has come up many many times in the past. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Aug 21 14:38:25 1999 Delivered-To: freebsd-smp@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 4C4C01545C for ; Sat, 21 Aug 1999 14:38:24 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id OAA89783; Sat, 21 Aug 1999 14:38:04 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: "Martin Dvorak" Cc: freebsd-smp@FreeBSD.ORG Subject: Re: SMP poor? In-reply-to: Your message of "Sat, 21 Aug 1999 09:20:42 CDT." <199908211420.JAA17618@db.geocrawler.com> Date: Sat, 21 Aug 1999 14:38:04 -0700 Message-ID: <89752.935271484@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >nothing... While o n RedHat I was copying large files in speed around >20MB/sec, now I am glad if I get to 5MB/sec. Also, untarring 1.5 MB >file takes about 40sec which is not wha t anyone could expect >mentioned hardware. You need to give more details on how you're measuring performance and what operations you're actually measuring. I see someone has already jumped up and suggested that this is a sync vs async thing, but that's kind of a silly suggestion since it would only affect you if you were creating or deleting many many files, it has no effect on the raw I/O performance to a single file. However, I can't give you any non-silly suggestions since you haven't given me any hard data to speak of. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Aug 21 20:36:28 1999 Delivered-To: freebsd-smp@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 5767414EE9 for ; Sat, 21 Aug 1999 20:36:24 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id XAA09443; Sat, 21 Aug 1999 23:34:45 -0400 (EDT) (envelope-from luoqi) Date: Sat, 21 Aug 1999 23:34:45 -0400 (EDT) From: Luoqi Chen Message-Id: <199908220334.XAA09443@lor.watermarkgroup.com> To: blanquer@cs.ucsb.edu, luoqi@watermarkgroup.com Subject: Re: SMP differences between -stable and -current (RE: wine and SMP) Cc: freebsd-smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Do you have any docs explaining this? I mean the way you are > implementing it...The docs I've seen are usually explaining possible > strategies and problems, but it's difficult to know the actual status of > it. Of course one can always take a look to the kernel code, but it's > not easy task, specially because the SMP code it's kinda sparse... Unfortunately I don't have any docs. But I can explain briefly what I have done. To move interrupt handler out of GKL, we have to rely on spin locks for critical region protection. The problem with spin locks is that they are often nested and could be in any order, potential deadlock hazards. The solution is to acquire GKL when we need to raise cpl the 2nd time (the first time is when the interrupt handler is entered), this is not always possible and interrupt handler can't wait. If we can't get GKL to come to us, we go to GKL: we suspend the interrupt handler and forward it to the GKL holder via an IPI, and the lock holder would complete the rest. This effectively pushs GKL down to the boundary of spl calls (so I didn't move interrupt handlers completely outside the GKL, but most of them), this is probably the furthest we could go without the introduction of finer grained subsystem locks. > With some docs about the actual implementation would be much more easy > for others to start playing with things like proc. affinity and many other > performance improvements... > > BTW is that code going to be part of -current? if so, do you know when > (aprox)? > I hope so. Timewise, I don't know. I have just successfully finished a make world after closing down one last race window today, so at least the idea works. But the code is a mess, I need to clean it up, probably rework some part, and deal with cases I currently ignored. > Nice, that should really make a difference in for example server boxes > with a lot of traffic... > It didn't improvement the make world time, but that's no surprise, interrupts account for less than 1% of cpu usage. It should help, e.g., a web server, with simultaneous disk and network activities, but I don't have a test environment. > Josep M. > -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message