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